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.
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
20 matches
Mail list logo
