[9fans] Git usage

[9fans] Git usage

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

Now that I'm doing some daily development, I'm running into process issues
with git.  That probably means I'm doing something wrong, and I'm hoping
someone might disabuse me.

My workflow is to sync my github fork of rminnich/nixos, then git/pull to
get up to date with my repo.  I then make a branch for my work: git/branch
-b remotes/origin/regen -n some_feature
After some time, I commit my changes and git/push.  I can then generate the
pull request on github and manage the review there, etc, then delete the
branch on github, then 'git/branch regen && git/branch -d some_feature' to
clean up my world.

This almost works, but leaves a bunch of remotes in my repo:

fluxcpu% git/branch -a
heads/master
heads/fix_multiboot_magic
heads/keep
heads/_rebase.working
heads/fix_mp_init
heads/some_feature
remotes/origin/master
remotes/origin/regen
remotes/origin/boots
remotes/origin/multiboot_magic
remotes/origin/fix_multiboot_magic
remotes/origin/fix_mp_init


What's the right way to clean up these ever-growing remotes?

Paul

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-M52fa9db12231eab2db9e5b93
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2091 bytes --]

Re: [9fans] Git usage

[Ron Minnich]

with the Linus git, you can
git push origin :multiboot_magic
and it's gone.

 Not quite sure about Ori's git.

That's the only way I've done it.

I actually have 540 branches at my u-root fork, so I'm hardly a good
example. I leave them lying around for reference.

On Sun, Jan 12, 2025 at 11:56 AM Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
>
> Now that I'm doing some daily development, I'm running into process issues with git.  That probably means I'm doing something wrong, and I'm hoping someone might disabuse me.
>
> My workflow is to sync my github fork of rminnich/nixos, then git/pull to get up to date with my repo.  I then make a branch for my work: git/branch -b remotes/origin/regen -n some_feature
> After some time, I commit my changes and git/push.  I can then generate the pull request on github and manage the review there, etc, then delete the branch on github, then 'git/branch regen && git/branch -d some_feature' to clean up my world.
>
> This almost works, but leaves a bunch of remotes in my repo:
>
> fluxcpu% git/branch -a
> heads/master
> heads/fix_multiboot_magic
> heads/keep
> heads/_rebase.working
> heads/fix_mp_init
> heads/some_feature
> remotes/origin/master
> remotes/origin/regen
> remotes/origin/boots
> remotes/origin/multiboot_magic
> remotes/origin/fix_multiboot_magic
> remotes/origin/fix_mp_init
>
>
> What's the right way to clean up these ever-growing remotes?
>
> Paul
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-M109728b2986065587044e919
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Git usage

[Christopher Nielsen]

[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]

Like Ron, I also leave my branches around for reference unless I know for
certain I will never have any use for them. That's just my workflow,
though. Others will probably have different ideas.

Chris

On Sun, Jan 12, 2025, 14:14 Ron Minnich <rminnich@p9f.org> wrote:

> with the Linus git, you can
> git push origin :multiboot_magic
> and it's gone.
>
>  Not quite sure about Ori's git.
>
> That's the only way I've done it.
>
> I actually have 540 branches at my u-root fork, so I'm hardly a good
> example. I leave them lying around for reference.
>
> On Sun, Jan 12, 2025 at 11:56 AM Paul Lalonde <paul.a.lalonde@gmail.com>
> wrote:
> >
> > Now that I'm doing some daily development, I'm running into process
> issues with git.  That probably means I'm doing something wrong, and I'm
> hoping someone might disabuse me.
> >
> > My workflow is to sync my github fork of rminnich/nixos, then git/pull
> to get up to date with my repo.  I then make a branch for my work:
> git/branch -b remotes/origin/regen -n some_feature
> > After some time, I commit my changes and git/push.  I can then generate
> the pull request on github and manage the review there, etc, then delete
> the branch on github, then 'git/branch regen && git/branch -d some_feature'
> to clean up my world.
> >
> > This almost works, but leaves a bunch of remotes in my repo:
> >
> > fluxcpu% git/branch -a
> > heads/master
> > heads/fix_multiboot_magic
> > heads/keep
> > heads/_rebase.working
> > heads/fix_mp_init
> > heads/some_feature
> > remotes/origin/master
> > remotes/origin/regen
> > remotes/origin/boots
> > remotes/origin/multiboot_magic
> > remotes/origin/fix_multiboot_magic
> > remotes/origin/fix_mp_init
> >
> >
> > What's the right way to clean up these ever-growing remotes?
> >
> > Paul
> > 9fans / 9fans / see discussions + participants + delivery options
> Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-M1fa1aff33e0459f051eba634
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3785 bytes --]

[9fans] Re: Git usage

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]

My next question is how to pull new changes from remote while putting my
new work on top.
Linus' git does a decent job of that with pull, but my experience with git9
is rather less pleasant.

Looking at it, it seems like a work for git/rebase.  Here I'm trying to
take the work from

fluxcpu% git/branch

heads/some_feature

fluxcpu% git/rebase remotes/origin/regen
refs/heads/_rebase.working: 7664f5db108af0debf257470be6ac3126ee0206b
pick 44574500459e507d51e6a359ebe6fd2a1c3df1da Save these files for later.
diff: cannot open b/386/bin/ape//null: file does not exist:
'b/386/bin/ape//null'
diff: cannot open b/386/bin/auth//null: file does not exist:
'b/386/bin/auth//null'
diff: cannot open b/386/bin/aux//null: file does not exist:
'b/386/bin/aux//null'
...

Rebase appears to be both expensive, and perhaps buggy?  I'm not sure
what's up with the very long scroll of the same error, applied to different
files.

This is also too slow to be usable, at least for a tree as large as NIX.
We'll get NIX pruned down into small changes to bind over 9front, but I
don't see how to update my working branch to track upstream.

Any advice?

On Sun, Jan 12, 2025 at 11:55 AM Paul Lalonde <paul.a.lalonde@gmail.com>
wrote:

> Now that I'm doing some daily development, I'm running into process issues
> with git.  That probably means I'm doing something wrong, and I'm hoping
> someone might disabuse me.
>
> My workflow is to sync my github fork of rminnich/nixos, then git/pull to
> get up to date with my repo.  I then make a branch for my work: git/branch
> -b remotes/origin/regen -n some_feature
> After some time, I commit my changes and git/push.  I can then generate
> the pull request on github and manage the review there, etc, then delete
> the branch on github, then 'git/branch regen && git/branch -d some_feature'
> to clean up my world.
>
> This almost works, but leaves a bunch of remotes in my repo:
>
> fluxcpu% git/branch -a
> heads/master
> heads/fix_multiboot_magic
> heads/keep
> heads/_rebase.working
> heads/fix_mp_init
> heads/some_feature
> remotes/origin/master
> remotes/origin/regen
> remotes/origin/boots
> remotes/origin/multiboot_magic
> remotes/origin/fix_multiboot_magic
> remotes/origin/fix_mp_init
>
>
> What's the right way to clean up these ever-growing remotes?
>
> Paul
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-M0b73ad2941119c82f0570bb4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4090 bytes --]

Re: [9fans] Re: Git usage

[Noam Preil]

git/merge might work a bit faster, but making it smarter was on the list
of things I wanted to get to right before my 9front laptop broke :P

Both merge and rebase, IIRC, will try comparing every path on either
side (or all three sides for 3-way merges, rather), even if e.g. the
parent directory doesn't exist.

So if you do e.g.

% mkdir /tmp/foo
% cd /tmp/foo
% git/init
% touch foo
% git/add foo
% git/commit -m 'initial commit' foo
% git/branch -nb front tmp
# Copy the entire Go tree in here
% clone -v /tmp/go/* .
% git/add go
% git/commit -m 'add go' go
% git/branch front

Any merge you do between these two branchs will check EVERY PATH IN THE
GO TREE, even though go only exists on one side.

What we basically need is for diff3 or merge to take in the roots, and
walk the tree intelligently, writing off entire directories rather than
attempting every child.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-Mf1ab01ebcdede815cdb8aba5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Git usage

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

Validating every file as you describe makes sense if there is no common
ancestor.
In the case of trees with a common ancestor, however, only files changed in
subsequent commits should require checking.
I went digging around git/fs and I don't see a way to get the files
associated with a given commit.
@Ori Bernstein <ori@eigenstate.org> Is there a tool in 9git that lets me
list which files were changed at a given commit hash?

Paul

On Sun, Jan 12, 2025 at 1:58 PM Noam Preil <noam@pixelhero.dev> wrote:

> git/merge might work a bit faster, but making it smarter was on the list
> of things I wanted to get to right before my 9front laptop broke :P
>
> Both merge and rebase, IIRC, will try comparing every path on either
> side (or all three sides for 3-way merges, rather), even if e.g. the
> parent directory doesn't exist.
>
> So if you do e.g.
>
> % mkdir /tmp/foo
> % cd /tmp/foo
> % git/init
> % touch foo
> % git/add foo
> % git/commit -m 'initial commit' foo
> % git/branch -nb front tmp
> # Copy the entire Go tree in here
> % clone -v /tmp/go/* .
> % git/add go
> % git/commit -m 'add go' go
> % git/branch front
> 
> Any merge you do between these two branchs will check EVERY PATH IN THE
> GO TREE, even though go only exists on one side.
> 
> What we basically need is for diff3 or merge to take in the roots, and
> walk the tree intelligently, writing off entire directories rather than
> attempting every child.
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-Mf7d5e4599a717ca072cb06ed
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3214 bytes --]

Re: [9fans] Re: Git usage

[Noam Preil]

There is, qit/query has a flag for it.

We're currently using git/walk to fetch them - oh! We should only need
to diff _modified_ files, whereas we currently also diff files which are
_added_ or _removed_ as well, iirc.

I'm currently setting up my replacement 9front system, I'll take a look
shortly!


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-Mff136c41de12e02e7ab4cecd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Git usage

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

Nice, I can kind of make it work for me:

fluxcpu% git/query -c  'dcc6924f24d885f48456a99575ac6619a8df9d45^^
61ce30435cd176e5967de641527656239db1e952'
@ sys/src/nix/k10/k8cpu
@ sys/src/nix/k10/l32p.s


Does the @ at the start of the lines have any significance?

Paul

On Sun, Jan 12, 2025 at 2:20 PM Noam Preil <noam@pixelhero.dev> wrote:

> There is, qit/query has a flag for it.
> 
> We're currently using git/walk to fetch them - oh! We should only need
> to diff _modified_ files, whereas we currently also diff files which are
> _added_ or _removed_ as well, iirc.
> 
> I'm currently setting up my replacement 9front system, I'll take a look
> shortly!
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-M281a92d5336c7d089d6ddf36
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2342 bytes --]

Re: [9fans] Re: Git usage

[ori]

Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> Nice, I can kind of make it work for me:
> 
> fluxcpu% git/query -c  'dcc6924f24d885f48456a99575ac6619a8df9d45^^
> 61ce30435cd176e5967de641527656239db1e952'
> @ sys/src/nix/k10/k8cpu
> @ sys/src/nix/k10/l32p.s
> 

Yes, there are 4 sigils:
        
        +       file was added
        -       file was removed
        @       file was changed
        !       perms were changed (possibly in addition to file contents)

I should probably update the manpage to document this better.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-M9bbb830a7266ac549ce71dcd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Git usage

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

Should these maybe match the outputs from git/walk?  '!' doesn't appear in
the git/walk output, should it?

Paul

On Sun, Jan 12, 2025 at 4:13 PM <ori@eigenstate.org> wrote:

> Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> > Nice, I can kind of make it work for me:
> >
> > fluxcpu% git/query -c  'dcc6924f24d885f48456a99575ac6619a8df9d45^^
> > 61ce30435cd176e5967de641527656239db1e952'
> > @ sys/src/nix/k10/k8cpu
> > @ sys/src/nix/k10/l32p.s
> >
>
> Yes, there are 4 sigils:
>
>         +       file was added
>         -       file was removed
>         @       file was changed
>         !       perms were changed (possibly in addition to file contents)
> 
> I should probably update the manpage to document this better.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-M02dfd80fd3d50ae9fe074247
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2579 bytes --]

Re: [9fans] Re: Git usage

[ori]

Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> Should these maybe match the outputs from git/walk?  '!' doesn't appear in
> the git/walk output, should it?
> 

sure, not a bad idea, though the meanings are somewhat different.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-Mb631e955cf2ec17ac6e87bc5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Git usage

[ori]

Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> My next question is how to pull new changes from remote while putting my
> new work on top.
> Linus' git does a decent job of that with pull, but my experience with git9
> is rather less pleasant.
> 
> Looking at it, it seems like a work for git/rebase.  Here I'm trying to
> take the work from
> 
> fluxcpu% git/branch
> 
> heads/some_feature
> 
> fluxcpu% git/rebase remotes/origin/regen
> refs/heads/_rebase.working: 7664f5db108af0debf257470be6ac3126ee0206b
> pick 44574500459e507d51e6a359ebe6fd2a1c3df1da Save these files for later.
> diff: cannot open b/386/bin/ape//null: file does not exist:
> 'b/386/bin/ape//null'
> diff: cannot open b/386/bin/auth//null: file does not exist:
> 'b/386/bin/auth//null'
> diff: cannot open b/386/bin/aux//null: file does not exist:
> 'b/386/bin/aux//null'
> ...
> 
> Rebase appears to be both expensive, and perhaps buggy?  I'm not sure
> what's up with the very long scroll of the same error, applied to different
> files.

I think most people on 9front git tend to not rebase all that often,
so it could probablly use a bit of love. That said, I'm pretty sure
that I fixed this a while go.

Do you have a way for me to repro this issue?

> This is also too slow to be usable, at least for a tree as large as NIX.
> We'll get NIX pruned down into small changes to bind over 9front, but I
> don't see how to update my working branch to track upstream.

if you have heads/mybranch and remotes/upstream/mybranch, then mybranch
will track upstream.

again, if you can give a repro, I can look at measuring why it's slow.

My typical workflow is that I'll work on a commit until it's ready, and
then either push it directly or cherry pick it onto front, and push it;
patches tend to be either an email of webpaste based workflow.

        git/import /mail/fs/mbox/$MSGID

is killer for pulling in a patch.

I've got a TODO list item to work on some nice patch queue tools based
on this, gerrit style, but it's not been a priority so far.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-Ma721d15ba8282138b2997903
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Git usage

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 3169 bytes --]

Ah, yes, my dev history involves git in very large repos with too many
committers.  The probability that you won't have to rebase to catch up to
main was approximately zero, so that just becomes part of the workflow.  If
you're the only person working in a section of the tree then it's trivial
and just runs automatically.

You may well have fixed it.  I realized that I hadn't done an update after
installing this cpu/disk server, so did that.  I'll report if I run into
the grief again.

Also, is there a reason why git/rebase -i doesn't have a "drop" option?  I
use it frequently when I find myself with a duplicate change from messing
up my github fork synchronizations.

Paul

On Sun, Jan 12, 2025 at 4:37 PM <ori@eigenstate.org> wrote:

> Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> > My next question is how to pull new changes from remote while putting my
> > new work on top.
> > Linus' git does a decent job of that with pull, but my experience with
> git9
> > is rather less pleasant.
> >
> > Looking at it, it seems like a work for git/rebase.  Here I'm trying to
> > take the work from
> >
> > fluxcpu% git/branch
> >
> > heads/some_feature
> >
> > fluxcpu% git/rebase remotes/origin/regen
> > refs/heads/_rebase.working: 7664f5db108af0debf257470be6ac3126ee0206b
> > pick 44574500459e507d51e6a359ebe6fd2a1c3df1da Save these files for later.
> > diff: cannot open b/386/bin/ape//null: file does not exist:
> > 'b/386/bin/ape//null'
> > diff: cannot open b/386/bin/auth//null: file does not exist:
> > 'b/386/bin/auth//null'
> > diff: cannot open b/386/bin/aux//null: file does not exist:
> > 'b/386/bin/aux//null'
> > ...
> >
> > Rebase appears to be both expensive, and perhaps buggy?  I'm not sure
> > what's up with the very long scroll of the same error, applied to
> different
> > files.
>
> I think most people on 9front git tend to not rebase all that often,
> so it could probablly use a bit of love. That said, I'm pretty sure
> that I fixed this a while go.
>
> Do you have a way for me to repro this issue?
>
> > This is also too slow to be usable, at least for a tree as large as NIX.
> > We'll get NIX pruned down into small changes to bind over 9front, but I
> > don't see how to update my working branch to track upstream.
> 
> if you have heads/mybranch and remotes/upstream/mybranch, then mybranch
> will track upstream.
> 
> again, if you can give a repro, I can look at measuring why it's slow.
> 
> My typical workflow is that I'll work on a commit until it's ready, and
> then either push it directly or cherry pick it onto front, and push it;
> patches tend to be either an email of webpaste based workflow.
> 
> git/import /mail/fs/mbox/$MSGID
> 
> is killer for pulling in a patch.
> 
> I've got a TODO list item to work on some nice patch queue tools based
> on this, gerrit style, but it's not been a priority so far.
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-M598b6db6edc61004d33a04c7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4988 bytes --]

Re: [9fans] Re: Git usage

[ori]

Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> Ah, yes, my dev history involves git in very large repos with too many
> committers.  The probability that you won't have to rebase to catch up to
> main was approximately zero, so that just becomes part of the workflow.  If
> you're the only person working in a section of the tree then it's trivial
> and just runs automatically.

Yes -- the other thing is that, unlike torvalds git, our git will try
to merge upstream changes against uncommitted local changes, which makes
it a lot easier to have some local divergences.

Improving local divergences is interesting to me, and I'd be happy to take
patches which improve that further. 'jj' looks like it may be a source of
inspiration, though I haven't played enough with it to know.

> 
> You may well have fixed it.  I realized that I hadn't done an update after
> installing this cpu/disk server, so did that.  I'll report if I run into
> the grief again.
> 
> Also, is there a reason why git/rebase -i doesn't have a "drop" option?  I
> use it frequently when I find myself with a duplicate change from messing
> up my github fork synchronizations

No, other than nobody implementing it -- but it's yours to change; feel free
to mention things that would improve your experiences. I'll happily take patches,
or at least discuss.

> 
> Paul
> 
> On Sun, Jan 12, 2025 at 4:37 PM <ori@eigenstate.org> wrote:
> 
> > Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> > > My next question is how to pull new changes from remote while putting my
> > > new work on top.
> > > Linus' git does a decent job of that with pull, but my experience with
> > git9
> > > is rather less pleasant.
> > >
> > > Looking at it, it seems like a work for git/rebase.  Here I'm trying to
> > > take the work from
> > >
> > > fluxcpu% git/branch
> > >
> > > heads/some_feature
> > >
> > > fluxcpu% git/rebase remotes/origin/regen
> > > refs/heads/_rebase.working: 7664f5db108af0debf257470be6ac3126ee0206b
> > > pick 44574500459e507d51e6a359ebe6fd2a1c3df1da Save these files for later.
> > > diff: cannot open b/386/bin/ape//null: file does not exist:
> > > 'b/386/bin/ape//null'
> > > diff: cannot open b/386/bin/auth//null: file does not exist:
> > > 'b/386/bin/auth//null'
> > > diff: cannot open b/386/bin/aux//null: file does not exist:
> > > 'b/386/bin/aux//null'
> > > ...
> > >
> > > Rebase appears to be both expensive, and perhaps buggy?  I'm not sure
> > > what's up with the very long scroll of the same error, applied to
> > different
> > > files.
> >
> > I think most people on 9front git tend to not rebase all that often,
> > so it could probablly use a bit of love. That said, I'm pretty sure
> > that I fixed this a while go.
> >
> > Do you have a way for me to repro this issue?
> >
> > > This is also too slow to be usable, at least for a tree as large as NIX.
> > > We'll get NIX pruned down into small changes to bind over 9front, but I
> > > don't see how to update my working branch to track upstream.
> > 
> > if you have heads/mybranch and remotes/upstream/mybranch, then mybranch
> > will track upstream.
> > 
> > again, if you can give a repro, I can look at measuring why it's slow.
> > 
> > My typical workflow is that I'll work on a commit until it's ready, and
> > then either push it directly or cherry pick it onto front, and push it;
> > patches tend to be either an email of webpaste based workflow.
> > 
> > git/import /mail/fs/mbox/$MSGID
> > 
> > is killer for pulling in a patch.
> > 
> > I've got a TODO list item to work on some nice patch queue tools based
> > on this, gerrit style, but it's not been a priority so far.
> > 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-M6f636d9af5f5ad46b85b0368
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Git usage

[ori]

Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> Ah, yes, my dev history involves git in very large repos with too many
> committers.  The probability that you won't have to rebase to catch up to
> main was approximately zero, so that just becomes part of the workflow.  If
> you're the only person working in a section of the tree then it's trivial
> and just runs automatically.
> 
> You may well have fixed it.  I realized that I hadn't done an update after
> installing this cpu/disk server, so did that.  I'll report if I run into
> the grief again.
> 
> Also, is there a reason why git/rebase -i doesn't have a "drop" option?  I
> use it frequently when I find myself with a duplicate change from messing
> up my github fork synchronizations.
> 

here's a quick diff I haven't yet tested for implementing drop -- let me know
if it does the job for you:

diff 2339cfc51541b3f62a7a92d67885b1918f8570c1 uncommitted
--- a/sys/src/cmd/git/rebase
+++ b/sys/src/cmd/git/rebase
@@ -59,6 +59,8 @@
        echo $item
        c=$item(2)
        switch($item(1)){
+       case d drop
+               # nothing to do
        case p pick
                git/export $c | git/import
        case r reword


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-Mda165161b1e8700d788c4fac
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Git usage

[Michael Forney]

Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
> Also, is there a reason why git/rebase -i doesn't have a "drop" option?  I
> use it frequently when I find myself with a duplicate change from messing
> up my github fork synchronizations.

You can drop a commit by simply deleting the line.

Re: [9fans] Git usage

[ori]

Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> Now that I'm doing some daily development, I'm running into process issues
> with git.  That probably means I'm doing something wrong, and I'm hoping
> someone might disabuse me.
> 
> My workflow is to sync my github fork of rminnich/nixos, then git/pull to
> get up to date with my repo.  I then make a branch for my work: git/branch
> -b remotes/origin/regen -n some_feature
> After some time, I commit my changes and git/push.  I can then generate the
> pull request on github and manage the review there, etc, then delete the
> branch on github, then 'git/branch regen && git/branch -d some_feature' to
> clean up my world.
> 
> This almost works, but leaves a bunch of remotes in my repo:
> 
> fluxcpu% git/branch -a
> heads/master
> heads/fix_multiboot_magic
> heads/keep
> heads/_rebase.working
> heads/fix_mp_init
> heads/some_feature
> remotes/origin/master
> remotes/origin/regen
> remotes/origin/boots
> remotes/origin/multiboot_magic
> remotes/origin/fix_multiboot_magic
> remotes/origin/fix_mp_init
> 
> 
> What's the right way to clean up these ever-growing remotes?
> 

        git/push -r rmbranch && git/branch -r rmbranch

Note, I just changed the flag name for removing a branch for
consistency, so you may need to sysupdate.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-M0e0916ac5d6623f1e865ee3d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription