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
Stefan Beller wrote:
> How would you know(/code) that v1.6.0-rc0~120^2 is a text worth linking?
> "v1.6.0-rc0" is a custom string as that is how we name tags in this
> project. It can follow any convention in other projects.
>
> Maybe a first approximation is if there is a `~` followed by numbers
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
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.
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
g
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, th
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 h
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 Chang
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 w
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.
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 th
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 t
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 rep
On 05/24/2015 07:28 AM, Christian Couder wrote:
> Hi,
>
> On Fri, May 22, 2015 at 4:38 PM, Stephen Kelly 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 &#x
On Tue, May 26, 2015 at 12:39 PM, Christian Couder
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
Galan Rémi 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 duplica
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 13
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
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
mak
Junio C Hamano wrote:
> Stephen Kelly 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
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 cons
21 matches
Mail list logo
