Re: Why doesn't gitk highlight commit references from git-describe?

[Stephen Kelly]

Stephen Kelly wrote:

>  cmake describe --contains


Oops, I mean git describe --contains of course.

Thanks,

Steve.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Why doesn't gitk highlight commit references from git-describe?

[Stephen Kelly]

Stefan Beller wrote:

> We also want to have 4b9ab0ee0130~1^2 to work `right`, in the sense
> that not just the hexadecimals are highlighted and linking to
> 4b9ab0ee0130, but the whole expression should link to 49e863b02ae177.

Presumably the same logic which finds 4b9ab0ee0130 to link it can also see 
if it is suffixed with '~1^2' ?

Is a ref like 4b9ab0ee0130~1^2 commonly useful? In cmake we use the output 
of cmake describe --contains (when there is a following tag) to refer to 
commits, in a pattern which I've also seen in git.git occasionally:

 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23f3798c

I think the only reason for using the output of cmake describe --contains is 
that it shows the reader the 'era' of the commit (and release it appears in) 
without having to look it up. I'm not really aware of another good reason to 
use it, but I think that's enough to make sense.

However I'm not sure I understand why anyone would refer to 4b9ab0ee0130~1^2 
instead of 49e863b0 (or perhaps v2.6.5~12, depending on whether the tag is 
there).

>> What does 'HEAD^' mean? If it is 'the commit before this one', then why
>> not link it?
> 
> As said I was thinking about the git development

> I do not think we would want to link HEAD to anything in that example.
> (I'd have no idea what it would link to here, so just not link it?)

Right, so if a commit message contains something like 

 Make git rebase -i HEAD ten times better

then HEAD shouldn't become a link. Makes sense to me.

Thanks,

Steve.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Why doesn't gitk highlight commit references from git-describe?

[Stephen Kelly]

Hi,

If I look at git commit 89ea90351dd32fbe384d0cf844640a9c55606f3b in gitk, it 
does not linkify the v1.6.0-rc0~120^2 in the commit message. 

Is there any reason for that, or can gitk be changed?

Thanks,

Steve.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 2/2] git rebase -i: Warn removed or dupplicated commits

[Stephen Kelly]

Galan Rémi remi.galan-alfonso at ensimag.grenoble-inp.fr writes:

 
 Check if commits were removed (i.e. a line was deleted) or dupplicated
 (e.g. the same commit is picked twice), can print warnings or abort
 git rebase according to the value of the configuration variable
 rebase.checkLevel.

I sometimes duplicate commits deliberately if I want to split a commit in
two. I move a copy up and fix the conflict, and I know that I'll still get
the right thing later even if I make a mistake with the conflict resolution.

Re: Pushing and pulling the result of `git replace` and objects/info/alternates

[Stephen Kelly]

On Tue, May 26, 2015 at 12:39 PM, Christian Couder
christian.cou...@gmail.com wrote:
 First it looks like you sent the email to me only, so I am replying to you 
 only.
 If this was a mistake, feel free to post this email to the Git mailing list.

Thanks, sorry for the mis-post.

 1) How would Alice push the content to a remote host so that Bob would
 get that automatically?

 I am not sure what you want exactly, but let me try to answer anyway.

 Let's suppose that the content is in another submodule, let's call it
 subA, and let's call subB the submodule that should reference content
 in subA.

Yes, that's the scenario in my script.

 If subA has been pushed on the remote host, then Bob can clone subA
 first, and then clone subB using the --reference option to point to
 the content of subA.

Ah. Here's some confusion maybe.

Alice pushes subA and subB *and* the supermodule. In my script, these
were named calculator, compute and appsuite. The supermodule is the
entry point that everyone uses.

Bob clones the supermodule, appsuite, and expects that to 'just work'
regarding history.

So, I want to somehow specify the --reference in the .gitmodules of
the appsuite supermodule. Then when Bob runs git submodule update
--init, the right thing will be done.


 Please note that I don't know much about git submodules, as I try not
 to use them myself,

Me too :), but needs must.

 so I am not sure there is a way to make them do
 exactly what you want. Maybe you should look at the threads about
 submodules on the Git mailing list, see who are the people involved
 and send an email on the list with those people in CC and a subject
 related to submodules and with your specific questions about
 submodules in the content.

Ok, thanks. I think the solution of running a script after initial
clone/update is probably the most suitable for now anyway without
getting deeper into git.

 For example I don't know if there is a way to tell that subA should be
 cloned before subB or something like that.

Right. A step of performing actions like this would need to be done
after all fetches are done I guess.

 2) Can git submodules be configured to use particular options when
 cloning particular repos? I see no relevant options in the

  https://www.kernel.org/pub/software/scm/git/docs/gitmodules.html

 page.

 I don't know. Maybe it's possible to add a
 submodule.name.cloneOptions option to specify them. Or maybe it's
 possible to use the submodule.name.update config option with a
 specific command (see custom command in
 http://git-scm.com/docs/git-submodule) to do it.

Yes, actually the 'custom command' section there might be useful... I
might try it.

 You might also be able to clone using an option like --config
 remote.origin.fetch = 'refs/replace/*:refs/replace/*' to fetch the
 replace ref when cloning.

 Cool, but I guess the same second question applies here about whether
 a submodule can be configured to fetch like that when the user does a
 update --init ?

 Yeah, the same question applies.

 Otherwise, I'm not sure what you are suggesting.

 I am not suggesting anything else.

 echo ../../calculator/objects 
 ../.git/modules/compute/objects/info/alternates
 git replace --graft HEAD $extraction_sha
 Maybe use the following instead of the above line:

 git fetch 'refs/replace/*:refs/replace/*'

 Thanks.

 # And now we see the history from the calculator repo. Great. But, it
 required user action after the clone.
 Yeah, but if the 2 above commands are in a script maybe it's
 reasonable to ask the user to launch the script once after cloning.

 Would it be possible to do this in a hook in the 'integration repo'
 which contains both submodules in the example I posted? Like a fetch
 hook or something?

 It is possible to do whatever you want in a hook, but the question is
 why would you do it in a hook as it looks like it needs to be done
 only once?

 Or maybe I am missing something?

 The goal is to make it transparent to users, so that no one needs to
 remember to 'do something once', but just gets a working checkout by
 cloning the submodule in the plain, normal, 'what you learn on day
 one' way. That is,

 git clone git://some/remote/appsuite appsuite-clone
 cd appsuite-clone
 git submodule update --init
 cd compute
 ls ../.git/modules/compute/objects/info
 git log --oneline

 should show the history despite the split.

 Yeah, it would be nice if that would work, but, I am not sure it can
 work like that right now.

 And using hooks doesn't change anything as you have to setup those hooks 
 anyway.

 So it looks like you might just need to clone with a few more options
 than usual.

 I haven't tested it so please tell me if it works :-)

 I changed the last 20 or so lines with one of your suggestions. I put
 the initial revision and the update on a gist:

  https://gist.github.com/steveire/a57bc48a460e11284d81/revisions

 The script I posted is easy to modify if you want to try something
 out. I would be happy if you 

Re: Pushing and pulling the result of `git replace` and objects/info/alternates

[Stephen Kelly]

On 05/24/2015 07:28 AM, Christian Couder wrote:
 Hi,

 On Fri, May 22, 2015 at 4:38 PM, Stephen Kelly steve...@gmail.com wrote:
 I have tried out using `git replace --graft` and
 .git/objects/info/alternates to 'refer to' the history in the origin
 repo instead of 'duplicating' it. This is similar to how Qt5 repos
 refer to Qt 4 history in a different repo.

 Question 1) Is this a reasonable thing to do for this scenario?
 I think it should work without too much work, but see the answer to
 the next question.

Ok, thanks. The concern is that there is plenty of documentation for
git-filter-branch, but no documentation or porcelain for info/alternates
and little out on the internet about it or git replace and using them
together.

However, it seems to be a reasonable thing to do.

 echo ../../calculator/objects 
 ../.git/modules/compute/objects/info/alternates
 git replace --graft HEAD $extraction_sha
 Maybe use the following instead of the above line:

 git fetch 'refs/replace/*:refs/replace/*'

Thanks.

 # And now we see the history from the calculator repo. Great. But, it
 required user action after the clone.
 Yeah, but if the 2 above commands are in a script maybe it's
 reasonable to ask the user to launch the script once after cloning.

Would it be possible to do this in a hook in the 'integration repo'
which contains both submodules in the example I posted? Like a fetch
hook or something?

Thanks,

Steve.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pushing and pulling the result of `git replace` and objects/info/alternates

[Stephen Kelly]

Hello,

I have an 'integration repo' which contains other git repos as submodules.

One of the submodules is to be split in two to extract a library.

A common way of doing that is to use git-filter-branch. A disadvantage
of that is that it results in duplicated partial-history in the
extracted repo. So, git log shows the entire history, but there is not
one canonical sha which represents the history at that point. The
split repo will contain 'false history', and checking it out will not
be useful.

So, I want to avoid git-filter-branch.

I have tried out using `git replace --graft` and
.git/objects/info/alternates to 'refer to' the history in the origin
repo instead of 'duplicating' it. This is similar to how Qt5 repos
refer to Qt 4 history in a different repo.

Question 1) Is this a reasonable thing to do for this scenario?

Question 2) Is there a way to push the `git replace` result and the
`info/alternates` content so that clients cloning the 'integration
repo' do not have to do that 'manually' or with a 'setup-repo.sh'
script?

The sequence of commands below can be pasted into a tmp directory to
see the scenario in action.

Thanks!


mkdir calculator
cd calculator
mkdir mainui libcalc
echo print \hello\  mainui/app.py
echo print \hello\  libcalc/adder.py
echo print \hello\  libcalc/subtracter.py
git init
git add .
git commit -am Initial commit
git checkout `git rev-parse HEAD`

cd ..
mkdir appsuite
cd appsuite
git init
git submodule add ../calculator
git commit -m Add calculator submodule

# Add other submodules in the suite...

cd calculator

echo print \goodbye\  libcalc/subtracter.py
git add libcalc/subtracter.py
git commit -am Fix bug in subtracter

echo print \Hi\  libcalc/adder.py
git add libcalc/adder.py
git commit -am Make adder more efficient

echo print \Hello, world!\  mainui/app.py
git add mainui/app.py
git commit -am Improve app

echo print \hello, hello\  libcalc/multiplier.py
git add libcalc/multiplier.py
git commit -am Add multiplier

cd ..
git add calculator
git commit -m Update calculator submodule

mkdir compute
cd calculator
mv libcalc ../compute

extraction_sha=`git rev-parse HEAD`
git commit -am Remove libcalc from calculator repo -m It is moved
to a new compute repo
removal_sha=`git rev-parse HEAD`
git push

cd ../compute
git init
git add .
git commit -m Create the compute repo. -m This commit will not be
normally visible after the replace --graft below.

echo This is the compute framework. It contains the libcalc library.  README
git add README
git commit -m Initialize the compute repo. -m This has been
extracted from calculator.git at $removal_sha
git checkout `git rev-parse HEAD`

cd ..
mv compute ..
git submodule add ../compute

git add calculator compute
git commit -m Split compute framework out of calculator repo.

cd compute
git log --oneline
# We don't see older history from the calculator repo

# Let's add alternates
echo ../../calculator/objects 
../.git/modules/compute/objects/info/alternates

# ... and graft onto the extraction commit
git replace --graft HEAD $extraction_sha

git log --oneline
# Great, now we see history from the calculator repo.

cd ../..
git clone appsuite appsuite-clone
cd appsuite-clone
git submodule update --init
cd compute
ls ../.git/modules/compute/objects/info
git log --oneline
# The replacement and alternatives did not get cloned ... :(

echo ../../calculator/objects 
../.git/modules/compute/objects/info/alternates
git replace --graft HEAD $extraction_sha

# And now we see the history from the calculator repo. Great. But, it
required user action after the clone.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

Jens Lehmann wrote:

 Am 23.06.2014 20:24, schrieb Stephen Kelly:
 Stephen Kelly wrote:
 
 I see that gitk is showing the output of git diff --submodule, similar
 to git submodule summary.
 
 Right, and for your use case --submodule would have to learn a
 different value in addition to 'log' and 'short'. And the default
 is already configurable via the 'diff.submodule' config option.

Right.

 Assuming that is not going to be changed, maybe I can hack
 parseblobdiffline locally. I have not really tried to read of write tcl
 code before though, so I'd still prefer a 'proper' solution somehow.
 
 I'd prefer a proper solution too, which is exactly why I tried
 to understand your use case first before speculating about how
 it could be solved.

Thanks for your help!

 I dug deeper and came up with this patch which suits my needs:
 
 Yup, I think that's the core of the change necessary to help
 your workflow.

Ok, so I guess we can add --summary=commits ?

I don't write C code generally, so I'm not certain how that needs to be 
propagated.

Thanks,

Steve.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

Stephen Kelly wrote:

 But I agree that this is suboptimal for your workflow. What about adding
 a Visualize These Changes In The Submodule menu entry for the context
 menu of a change in gitk just like the one git gui already has?
 
 Can you tell me how to find and try that out in git gui?

In particular, I don't see it in my git gui. Is it only in master?

My versions:

 git-gui version 0.18.0.14.g1b2c7
 git version 1.9.1

 Tcl/Tk version 8.6.1
 Aspell 0.60.7-20110707, en_US

Thanks,

Steve.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

Jens Lehmann wrote:

 Am 22.06.2014 17:45, schrieb Stephen Kelly:
 Jens Lehmann wrote:
 
 Am 22.06.2014 16:09, schrieb Stephen Kelly:
 But I agree that this is suboptimal for your workflow. What about adding
 a Visualize These Changes In The Submodule menu entry for the context
 menu of a change in gitk just like the one git gui already has?
 
 Can you tell me how to find and try that out in git gui?
 
 Sure, you'll find that in the pop-up menu when right clicking the
 submodule summary in the diff pane (where you can choose to stage
 or unstage hunks or lines for regular files).

Thanks. I see it the feature now.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

Jens Lehmann wrote:

 But I agree that this is suboptimal for your workflow. What about adding
 a Visualize These Changes In The Submodule menu entry for the context
 menu of a change in gitk just like the one git gui already has? Then the
 user could examine the merges in more detail if he wants.

Such a menu entry might be useful,  but it is still different workflow. It 
would be useful in the 'that commit sounds interesting - show me' case. I 
would need to see the commit title to know if it sounds interesting though. 

Your suggestion involves a different window and context, but all I want to 
see is a list of commit titles so I can press 'up' to see the next ones, not 
have to close a window first before I can see the next list, and then have 
to right-click to see the list of commits.

Is it so difficult to list the titles of all of the newly-reachable commits? 
Even with a config option? Even an undocumented option? 

Failing all of that, can you show me where the code would need to be changed 
to list all of the newly-reachable commits? I can keep a commit for myself 
then.

Thanks,

Steve.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

Stephen Kelly wrote:

 Failing all of that, can you show me where the code would need to be
 changed to list all of the newly-reachable commits? I can keep a commit
 for myself then.

I see that gitk is showing the output of git diff --submodule, similar to 
git submodule summary.

Assuming that is not going to be changed, maybe I can hack parseblobdiffline 
locally. I have not really tried to read of write tcl code before though, so 
I'd still prefer a 'proper' solution somehow.

Thanks,

Steve.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

Stephen Kelly wrote:

 I see that gitk is showing the output of git diff --submodule, similar to
 git submodule summary.
 
 Assuming that is not going to be changed, maybe I can hack
 parseblobdiffline locally. I have not really tried to read of write tcl
 code before though, so I'd still prefer a 'proper' solution somehow.

I dug deeper and came up with this patch which suits my needs:

diff --git a/submodule.c b/submodule.c
index b80ecac..0dacd61 100644
--- a/submodule.c
+++ b/submodule.c
@@ -297,7 +297,7 @@ static int prepare_submodule_summary(struct rev_info 
*rev, const char *path,
init_revisions(rev, NULL);
setup_revisions(0, NULL, rev, NULL);
rev-left_right = 1;
-   rev-first_parent_only = 1;
+  rev-max_parents = 1;
left-object.flags |= SYMMETRIC_LEFT;
add_pending_object(rev, left-object, path);
add_pending_object(rev, right-object, path);


The 'merge pull request' merges are only noise to me.

Thanks,

Steve.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

gitk with submodules does not show new commits on other branches

[Stephen Kelly]

Hello,

boost.git, is using submodules. 

If I run gitk after a pull, there are some messages along the lines of 


Update preprocessor from develop.

  Submodule libs/preprocessor 9d2d1ff..1422fce:
Merge branch 'master' into develop


That is, it shows only the merge. 

If I then run 

 git log --oneline 9d2d1ff..1422fce 

I can see the commits which were made on master and then merged into 
develop. Please show the same information (ie all commits newly reachable 
from develop) in the submodule gitk output.

Thanks,

Steve.






--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

Jens Lehmann wrote:

 Am 22.06.2014 16:09, schrieb Stephen Kelly:

 Please show the same information (ie all commits newly reachable
 from develop) in the submodule gitk output.
 
 This should not happen by default. If you have a feature branch based
 workflow, the merge is just what you want to see.

In my case, it is not what I want to see :).

 But I agree that this is suboptimal for your workflow. What about adding
 a Visualize These Changes In The Submodule menu entry for the context
 menu of a change in gitk just like the one git gui already has?

Can you tell me how to find and try that out in git gui?

Thanks,

Steve.



--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git interactive rebase 'consume' command

[Stephen Kelly]

Junio C Hamano wrote:

 Stephen Kelly steve...@gmail.com writes:

 One scenario is something like this:

  Start with a clean HEAD (always a good idea :) )
  hack hack hack
  make multiple commits
  realize that a hunk you committed in an early patch belongs in a later
  one. use git rebase -i to fix it.

 Is that more clear?
 
 Not really.

I think there are other scenarios, but I guess this won't happen anyway.

Thanks,

Steve.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git interactive rebase 'consume' command

[Stephen Kelly]

On 01/21/2013 12:05 PM, Michael Haggerty wrote:

It is perverse to have to turn a well-defined and manifestly
conflict-free wish into one that has a good chance of conflicting, just
because of a limitation of the tool.


Yes, I agree.


I would prefer to be able to mark a commit as 'should be consumed', so that:

  pick 07bc3c9 Good commit.
  consume 1313a5e Commit to fixup into c2f62a3.
  pick c2f62a3 Another commit.

will result in

  pick 07bc3c9 Good commit.
  pick 62a3c2f Another commit.

directly.

Excellent.  But the name is not self-explanatory.  And there is
something different about your consume command:

Normally, pick means that the commit on that line is the start of a
new commit unrelated to its predecessors.  And in general, the command
on one line only affects the lines that come before it, not the lines
that come after it.  Under your proposal consume would change the
meaning of the following line, namely by changing what its pick means.



  It might be more consistent to require the following line to be changed
to squash:


I'm -1 on that. I value the simple format of the todo file. If I want to 
edit a commit, I type deif, reword - deir, fixup - deif. I'd like 
something equally simple like deic for this operation. There's also a 
'consistency' argument there, and one I prefer to your consistency 
interpretation.


The same simplicity request applies to what you write below.

Thanks,

Steve.


 pick 07bc3c9 Good commit.
 consume 1313a5e Commit to fixup into c2f62a3.
 squash c2f62a3 Another commit.

in which case the meaning of consume would be something like pick
this commit but not its commit message.  There would have to be a
prohibition against generating commits with *no* commit messages, to
prevent series like [consume, pick] or [consume, fix, pick] while
allowing series like [consume, consume, squash, fix, fix].

If this is the interpretation, the name quiet/q might make things clearer.

Yet another approach would be to allow options on the commands.  For
example,

 pick 07bc3c9 Good commit.
 pick --quiet 1313a5e Commit to fixup into c2f62a3.
 squash c2f62a3 Another commit.

In fact if options were implemented, then fixup would mean the same as
squash --quiet, reword could be written pick --edit, and I'm sure
the new flexibility would make it easier to add other features (e.g.,
pick --reset-author).

Michael



--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git interactive rebase 'consume' command

[Stephen Kelly]

Hi there,

I find the fixup command during an interactive rebase useful.

Sometimes when cleaning up a branch, I end up in a situation like this:

 pick 07bc3c9 Good commit.
 pick 1313a5e Commit to fixup into c2f62a3.
 pick c2f62a3 Another commit.


So, I have to reorder the commits, and change 1313a5e to 'f'. An alternative 
would be to squash 's' c2f62a3 into 1313a5e and clean up the commit message. 
The problem with that is it ends up with the wrong author time information.

So, I usually reorder and then fixup, but that can also be problematic if I 
get a conflict during the re-order (which is quite likely).

I would prefer to be able to mark a commit as 'should be consumed', so that:

 pick 07bc3c9 Good commit.
 consume 1313a5e Commit to fixup into c2f62a3.
 pick c2f62a3 Another commit.

will result in 

 pick 07bc3c9 Good commit.
 pick 62a3c2f Another commit.

directly.

Any thoughts on that? 

Thanks,

Steve.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git interactive rebase 'consume' command

[Stephen Kelly]

John Keeping wrote:
 Any thoughts on that?
 
 Are you aware of the --autosqush option to git-rebase (and the
 rebase.autosquash config setting)?  I find that using that combined
 with the --fixup option to git-commit makes this workflow a lot more
 intuitive.

Yes, I'm aware of it, but I think it's not related to the proposal I made. 

Mostly my proposal is about avoiding unnecessary conflict resolution.

Thanks,

Steve.




--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git interactive rebase 'consume' command

[Stephen Kelly]

Junio C Hamano wrote:
 Sorry, but I do not understand what you are trying to solve.
 
 How can 1313a5e, which fixes misakes made in c2f62a3, come before
 that commit in the first place?

One scenario is something like this:

 Start with a clean HEAD (always a good idea :) )
 hack hack hack
 make multiple commits
 realize that a hunk you committed in an early patch belongs in a later one.
 use git rebase -i to fix it.


Is that more clear?

Thanks,

Steve.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html