Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:

> I still haven't received a response: which makes more sense?
>
> a)
>
> 	% git checkout svn-ext
> 	% git fetch
> 	From .
> 	 * branch            master     -> FETCH_HEAD
> 	# oops
> 	% git fetch git-svn
> 	% git log ..FETCH_HEAD
> 	% git merge FETCH_HEAD
>
> b)
>
> 	% git checkout svn-ext
> 	% git fetch
> 	From git://git.kernel.org/pub/scm/git/git
> 	   680ed3e..de3a5c6  master     -> origin/master
> 	# oops
> 	% git fetch svn-ext
> 	% git log ..FETCH_HEAD
> 	% git merge FETCH_HEAD

I think with the scenario you are following, a) would prepare the
FETCH_HEAD with her local git-svn branch which is her svn-ext topic
is based on, but you illustrated it to fetch 'master', which I think
is a minor typo.

Modulo that typo, the step before the #oops makes perfect sense.  It
fetched where she told Git her work on svn-ext is based on.

But the step after that does not make much sense in that flow.

"git fetch git-svn" to get from Eric might make sense but running
log with FETCH_HEAD while she is on her svn-ext does not make any
sense, let alone merging with it.  Her svn-ext is based on her local
git-svn branch for a reason---her branches are cascaded this way:

    Eric --> her local git-svn --> her local svn-ext

Hecking out her git-svn to update/rebase it on top of Eric's latest
and then update her svn-ext that is based on her git-svn may make
sense.  But fetching from Eric and merging it into her svn-ext
directly does not.

And what happens before #oops in b) is an utter nonsense.  Her
svn-ext is not even related to my tree.  I think the step after that
is a typo of "git fetch git-svn" to fetch from Eric, but again,
because svn-ext is fork from her local git-svn (which is ahead of
Eric's tree with her own changes, but the changes are not related
to her svn-ext work), these "fetch from Eric, integrate svn-ext directly
with it" makes no sense. 

So, the short answer is neither, but a) can be fixed (not in code
but in the typescript) to make more sense, perhaps like this:

    % git checkout svn-ext
    % git fetch
    % git log ..FETCH_HEAD
    % git rebase FETCH_HEAD
    # The last three can be "git pull --rebase".

    # ok, did Eric do something in the meantime?
    % git checkout git-svn
    % git fetch
    From git://git.bogomips.org/git-svn.git/
     * branch  master -> git-svn/master
    % git rebase FETCH_HEAD

    # now let's rebuild the svn-ext on top
    % git checkout svn-ext
    % git pull --rebase

The last step can be "git rebase git-svn", and the step to update
git-svn from Eric after checking it out can be "git pull --rebase",
but the whole point of having @{u}, even for branches that fork from
a local branch, is so that the user does not have to remember what
forks from what, so I did not force her to say "git rebase git-svn"
in that step.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]