Re: Feature request: different exit codes for git stash depending on whether stash was created or not
On 2019-09-27 at 12:55:27, Ian Kemp wrote: > Hi, > > Currently, git stash's exit code is 0 regardless of whether it > performed a stash operation or not. Third parties invoking git stash > are therefore unable to determine whether a stash was actually made or > not. > > It would be helpful if there were different exit codes for the case > when a stash was created (working directory dirty) vs when a stash was > not (working dir clean). git stash create suffers from the same issue. > > There are various workarounds for this e.g. > https://stackoverflow.com/a/34116244/70345 but they aren't > particularly pretty or reliable, hence this request. Folks have already given you a link to previous discussion, but if you want to know if there's anything to stash couldn't you use something like this: #!/bin/sh if [ -z "$(git status --porcelain)" ] then CLEAN=1 fi [ -n "$CLEAN" ] || git stash # your operation here [ -n "$CLEAN" ] || git stash pop An empty output from git status --porcelain is the definitive way to know if the working tree is clean, which is what you care about in this case. If you want to ignore untracked files, a suitable grep invocation can do that for you as well. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Re: Feature request: different exit codes for git stash depending on whether stash was created or not
On Fri, Sep 27, 2019 at 8:55 AM Ian Kemp wrote: > Currently, git stash's exit code is 0 regardless of whether it > performed a stash operation or not. Third parties invoking git stash > are therefore unable to determine whether a stash was actually made or > not. > > It would be helpful if there were different exit codes for the case > when a stash was created (working directory dirty) vs when a stash was > not (working dir clean). git stash create suffers from the same issue. There was a recent discussion[1] about this which might interest you. [1]: https://public-inbox.org/git/01020169a7ad6af3-ad50e2d1-19fb-46eb-b397-759f8d579e8b-000...@eu-west-1.amazonses.com/
Re: feature request, git-gui: add hotkey to toggle amend/new
On 12/09/19 12:04AM, Pratyush Yadav wrote:
> On 11/09/19 12:27PM, Birger Skogeng Pedersen wrote:
> > Hi Pratyush,
> >
> > I'm hoping this will be merged, even without changing the radio
> > selectors to a checkbox(?). The patch from Bert resolves the issue I
> > raised about wanting the hotkey.
> > What do you think?
>
> What do you mean by "this"? I am guessing you mean [0].
>
> I'm afraid that patch conflicts with Bert's change [1] to using a
> checkbox. Since both patches are in flight, it makes more sense to base
> your work off his. If I merge your patch now, I'll have to revert it as
> soon as it is time to merge Bert's, and then rework your patch.
>
> Also, after Bert's patch, the toggling becomes much simpler. All you'd
> have to do is something like:
>
> bind . <$M1B-Key-e> {
> # Toggle commit type.
> set commit_type_is_amend [expr {!$commit_type_is_amend}]
> do_select_commit_type
> }
I forgot to mention one more thing. You'd also want to mark the menu
entry of the amend toggle with Ctrl+e keybinding, like we do for all
other bindings (F5 for rescan, Ctrl+T for staging, etc.).
--
Regards,
Pratyush Yadav
Re: feature request, git-gui: add hotkey to toggle amend/new
On 11/09/19 12:27PM, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
>
> I'm hoping this will be merged, even without changing the radio
> selectors to a checkbox(?). The patch from Bert resolves the issue I
> raised about wanting the hotkey.
> What do you think?
What do you mean by "this"? I am guessing you mean [0].
I'm afraid that patch conflicts with Bert's change [1] to using a
checkbox. Since both patches are in flight, it makes more sense to base
your work off his. If I merge your patch now, I'll have to revert it as
soon as it is time to merge Bert's, and then rework your patch.
Also, after Bert's patch, the toggling becomes much simpler. All you'd
have to do is something like:
bind . <$M1B-Key-e> {
# Toggle commit type.
set commit_type_is_amend [expr {!$commit_type_is_amend}]
do_select_commit_type
}
Maybe a cleaner way is possible, but this is what I could come up with
for toggling a boolean.
So can you please send a re-roll based on Bert's patch? I took a quick
glance at it, and it seems mostly correct. I have a couple of comments,
so some things might change based on the discussion, but I don't think
it should affect your change too much.
[0] https://public-inbox.org/git/20190904175943.11924-1-birger...@gmail.com/
[1]
https://public-inbox.org/git/ab1f68cc8552e405c9d04622be1e728ab81bda17.1567713659.git.bert.wes...@googlemail.com/
--
Regards,
Pratyush Yadav
Re: feature request, git-gui: add hotkey to toggle amend/new
Hi Pratyush, I'm hoping this will be merged, even without changing the radio selectors to a checkbox(?). The patch from Bert resolves the issue I raised about wanting the hotkey. What do you think? Birger
Re: feature request, git-gui: add hotkey to toggle amend/new
On Wed, Sep 04, 2019 at 09:03:02PM +0200, Bert Wesarg wrote:
> On Wed, Sep 4, 2019 at 8:52 PM Johannes Sixt wrote:
> >
> > Am 04.09.19 um 19:46 schrieb Pratyush Yadav:
> > > On 04/09/19 08:24AM, Johannes Sixt wrote:
> > >> That is worth a try. The check box title offers a natural hotkey then:
> > >> "_A_mend last commit", Alt-a.
> > >
> > > Right now, the binding proposed is Ctrl-e. My mental model for the key
> > > bindings as of now is having the "actions" bound to Ctrl, and bindings
> > > that move you around in the UI bound to Alt. So it makes more sense to
> > > me to have a "amend toggle" bound to Ctrl. Maybe that's just me though.
> > > Anyone else care to chime in?
> >
> > "Amend last commit" is NOT an action. It switches a state.
> >
> > It is common in Windows GUIs that every control, including menu items,
> > has a hotkey associated, the underlined letter in the caption, and the
> > hotkey to access that UI control is Alt+that letter. It's not
> > necessarily a matter of moving around.
> >
> > And, BTW, this hotkey thing is also the case on my Linux desktop
> > (KDE-based).
> >
> > But of course, git-gui is different and totally off track here. It has
> > *zero* controls marked for hotkey-accessibility. I was just hoping to
> > spark an effort to make some of the controls marked and hotkey-accessible.
>
> I'm in favor of making this a checkbox, also in the menu. As all menu
> entries have currently a CTRL+ binding assigned, I think this one
> should have one too. As CTRL+A is taken, and the proposal is CTRL+E, I
> would be fine with this. If the menus and the UX elements also honors
> mnemonic now or in the future, I don't think they need to match the
> CTRL+ binding. Thus if this gets Alt+A I'm fine with this too.
>
> Bert
>
> >
> > -- Hannes
git-gui might not be so focused on providing a fast way to launch a
visual $EDITOR, but Ctrl+E is the hotkey we use everywhere in git-cola
when lauching external editors on selected files. Sometimes it's the
"hot" action so even "Enter" gets that action, but it's worth
considering if we ever want git-gui's status widget to be able to launch
editors.
We also let Ctrl+Enter launch the default xdg-open action on the
selected file (e.g. image files go to the default image editing program,
html files to a browser, etc).
While we're on the topic of hotkeys, some valuable hotkeys for an
English-centric keyboard are {J,K,L} because of the home row.
In web browsers, Ctrl-L is a very common hotkey for focusing the URL
input, so we stole that same hotkey for the "git log <...>" input
in the git-dag tool. In that tool the arguments to "log" are very
much like a URL from the input perspective, so it's nice to be able
to use a familiar and convenient hotkey for that purpose. The placement
of the input field[1] is also at the top of that tool, just like in a web
browser.
[1] https://git-cola.github.io/images/dag.png
Ctrl-L is also used to focus the "Commit summary" line edit for the main
git-cola commit message editor. That seems like the most sensible
"main" behavior for the main commit GUI. Maybe git-gui can do that too.
Ctrl-J is kinda like "down" in vim, and so we let that focus the "diff"
widget which is typically "down" below the status and commit widgets in
cola[2].
[2] https://git-cola.github.io/images/screenshot-dark-linux.png
Ctrl-K focuses the status widget because it's "up". Also, K and L are
adjacent on the keyboard, and they are also adjacent visually in the UI
so there's a visual and muscle memory pairing there between the Status
and Commit widgets.
The JKL hotkeys are nice to have in addition to the numeric hotkeys
because they're so convenient. In some cases (like when the diff widget
is focused) we allow Alt-{J,K} to jump down/up (next/prev) between the
files in the status widget, otherwise regular {J,K} can be used if it
has focus.
Thanks for at least trying to keep some parity with git-cola's hotkeys.
It's not completely possible in all situations, but it's good to at
least share notes on how we use the GUI.
--
David
Re: feature request, git-gui: add hotkey to toggle amend/new
On Wed, Sep 4, 2019 at 8:52 PM Johannes Sixt wrote: > > Am 04.09.19 um 19:46 schrieb Pratyush Yadav: > > On 04/09/19 08:24AM, Johannes Sixt wrote: > >> That is worth a try. The check box title offers a natural hotkey then: > >> "_A_mend last commit", Alt-a. > > > > Right now, the binding proposed is Ctrl-e. My mental model for the key > > bindings as of now is having the "actions" bound to Ctrl, and bindings > > that move you around in the UI bound to Alt. So it makes more sense to > > me to have a "amend toggle" bound to Ctrl. Maybe that's just me though. > > Anyone else care to chime in? > > "Amend last commit" is NOT an action. It switches a state. > > It is common in Windows GUIs that every control, including menu items, > has a hotkey associated, the underlined letter in the caption, and the > hotkey to access that UI control is Alt+that letter. It's not > necessarily a matter of moving around. > > And, BTW, this hotkey thing is also the case on my Linux desktop > (KDE-based). > > But of course, git-gui is different and totally off track here. It has > *zero* controls marked for hotkey-accessibility. I was just hoping to > spark an effort to make some of the controls marked and hotkey-accessible. I'm in favor of making this a checkbox, also in the menu. As all menu entries have currently a CTRL+ binding assigned, I think this one should have one too. As CTRL+A is taken, and the proposal is CTRL+E, I would be fine with this. If the menus and the UX elements also honors mnemonic now or in the future, I don't think they need to match the CTRL+ binding. Thus if this gets Alt+A I'm fine with this too. Bert > > -- Hannes
Re: feature request, git-gui: add hotkey to toggle amend/new
Am 04.09.19 um 19:46 schrieb Pratyush Yadav: > On 04/09/19 08:24AM, Johannes Sixt wrote: >> That is worth a try. The check box title offers a natural hotkey then: >> "_A_mend last commit", Alt-a. > > Right now, the binding proposed is Ctrl-e. My mental model for the key > bindings as of now is having the "actions" bound to Ctrl, and bindings > that move you around in the UI bound to Alt. So it makes more sense to > me to have a "amend toggle" bound to Ctrl. Maybe that's just me though. > Anyone else care to chime in? "Amend last commit" is NOT an action. It switches a state. It is common in Windows GUIs that every control, including menu items, has a hotkey associated, the underlined letter in the caption, and the hotkey to access that UI control is Alt+that letter. It's not necessarily a matter of moving around. And, BTW, this hotkey thing is also the case on my Linux desktop (KDE-based). But of course, git-gui is different and totally off track here. It has *zero* controls marked for hotkey-accessibility. I was just hoping to spark an effort to make some of the controls marked and hotkey-accessible. -- Hannes
Re: feature request, git-gui: add hotkey to toggle amend/new
Hi, You could argue that A (as in "amend") makes quite an intuitive hotkey. But personally I'm also leaning towards CTRL/CMD+E. The ALT+(letter) combination is used to open a menu, for instance ALT+R opens "Repository", ALT+E opens "Edit", etc. That's the behaviour on Windows, anyways. So the hotkeys may seem a bit "mixed up" when ALT+(some letter) opens the corresponding menu but ALT+A does something quite different. Birger
Re: feature request, git-gui: add hotkey to toggle amend/new
On 04/09/19 08:24AM, Johannes Sixt wrote: > Am 03.09.19 um 14:45 schrieb Pratyush Yadav: > > Can you try doing a Shift+Tab? For me on Linux, if I hit Shift+Tab, it > > immediately takes me to the "Amend last commit" option. Then I can press > > space to select it and Tab again to get back to the commit message. > > That works on Windows with Ctrl+Shift+Tab, too. > > > Also, since we are on this topic, how about making the "Amend last > > commit" button a toggle instead? This would act as a "turn amend mode > > on/off" button. Since "Amend last commit" and "New Commit" are mutually > > exclusive, a single toggle to switch between those modes makes sense to > > me. > > That is worth a try. The check box title offers a natural hotkey then: > "_A_mend last commit", Alt-a. Right now, the binding proposed is Ctrl-e. My mental model for the key bindings as of now is having the "actions" bound to Ctrl, and bindings that move you around in the UI bound to Alt. So it makes more sense to me to have a "amend toggle" bound to Ctrl. Maybe that's just me though. Anyone else care to chime in? -- Regards, Pratyush Yadav
Re: feature request, git-gui: add hotkey to toggle amend/new
Am 03.09.19 um 14:45 schrieb Pratyush Yadav: > Can you try doing a Shift+Tab? For me on Linux, if I hit Shift+Tab, it > immediately takes me to the "Amend last commit" option. Then I can press > space to select it and Tab again to get back to the commit message. That works on Windows with Ctrl+Shift+Tab, too. > Also, since we are on this topic, how about making the "Amend last > commit" button a toggle instead? This would act as a "turn amend mode > on/off" button. Since "Amend last commit" and "New Commit" are mutually > exclusive, a single toggle to switch between those modes makes sense to > me. That is worth a try. The check box title offers a natural hotkey then: "_A_mend last commit", Alt-a. -- Hannes
Re: feature request, git-gui: add hotkey to toggle amend/new
On 03/09/19 04:06PM, Birger Skogeng Pedersen wrote: > Hi Pratyush, > > > On Tue, Sep 3, 2019 at 2:45 PM Pratyush Yadav wrote: > > Can you try doing a Shift+Tab? For me on Linux, if I hit Shift+Tab, it > > immediately takes me to the "Amend last commit" option. Then I can press > > space to select it and Tab again to get back to the commit message. > > It seems that Shift+Tab doesn't do anything (on Windows 10). Ah, too bad. > Regardless, imo there should be a binding dedicated to toggle amend. > > > Also, since we are on this topic, how about making the "Amend last > > commit" button a toggle instead? This would act as a "turn amend mode > > on/off" button. Since "Amend last commit" and "New Commit" are mutually > > exclusive, a single toggle to switch between those modes makes sense to > > me. > > I assume you're talking about the button in the "Commit" dropdown Yes. That one and the two tick boxes on the top right of the commit message buffer/editor. > menu. I agree, it could be just a single entry which is a toggle to > enable/disable amending. And (above the commit message dialog) perhaps > just a single checkbox; "Amend Last Commit". In other git GUIs (Git > Cola and TortoiseGit) I see they're using just a single checkbox for > this option. But maybe that is a slightly different topic, the hotkey > behaviour would remain the same. Yes, of course your patch is independent of the two-button behaviour. I was just pointing it out to see how others feel about it. > > > > ... do you still feel the need for a dedicated binding for amends? > > How do you guys feel about it? So far it seems we're at two "yay" and > one "nay". I really feel it is in the best interest of the git-gui > project to implement this hotkey. And not just because it is my > personal preference to have it :-) Well, I do think amending commits is a common enough operation to warrant a dedicated keyboard binding for it. So it is a "yay" for this feature from my side at least. -- Regards, Pratyush Yadav
Re: feature request, git-gui: add hotkey to toggle amend/new
On 04/09/19 01:35AM, David wrote: > On Tue, 3 Sep 2019 at 22:45, Pratyush Yadav wrote: > > > > Can you try doing a Shift+Tab? For me on Linux, if I hit Shift+Tab, it > > immediately takes me to the "Amend last commit" option. Then I can press > > space to select it and Tab again to get back to the commit message. > > Hi Pratyush Yadav, > > Yes, we know it can be done this way. The point being made is not > "this cannot be changed with the keyboard". We know that you can > fool around with the tab key and the shift key and the spacebar and > eventually you can succeed in changing this option. Yes, but what Birger was saying was hitting Ctrl+Tab 9-10 times to get to the option. This is much faster than that alternative. My aim was to let people know what options already exist before proposing new ones. > And if you want to toggle it back again, you have to do a slightly > different keyboard dance, depending on where your cursor or > highlight is currently positioned. > > Rather what we (at least I) am hoping to communicate is that after you > have done this many thousands of times, and you can do everything > else in git-gui very fast without touching the mouse, you might also join > us in wishing for action to be achievable with one hotkey-combination > event that does not affect any other state, it just toggles new/amend > commit, and is not a sequence of several multi-key actions which must > be adapted according to the current status of other input mode actions. Don't get me wrong. I am not against having a dedicated hotkey for toggling amends. I think it is a common enough operation to warrant a dedicated keyboard toggle. I was just letting everyone know what the current options are, so they can make better judgements whether they really need this option or not. -- Regards, Pratyush Yadav
Re: feature request, git-gui: add hotkey to toggle amend/new
On Tue, 3 Sep 2019 at 22:45, Pratyush Yadav wrote: > > Can you try doing a Shift+Tab? For me on Linux, if I hit Shift+Tab, it > immediately takes me to the "Amend last commit" option. Then I can press > space to select it and Tab again to get back to the commit message. Hi Pratyush Yadav, Yes, we know it can be done this way. The point being made is not "this cannot be changed with the keyboard". We know that you can fool around with the tab key and the shift key and the spacebar and eventually you can succeed in changing this option. And if you want to toggle it back again, you have to do a slightly different keyboard dance, depending on where your cursor or highlight is currently positioned. Rather what we (at least I) am hoping to communicate is that after you have done this many thousands of times, and you can do everything else in git-gui very fast without touching the mouse, you might also join us in wishing for action to be achievable with one hotkey-combination event that does not affect any other state, it just toggles new/amend commit, and is not a sequence of several multi-key actions which must be adapted according to the current status of other input mode actions.
Re: feature request, git-gui: add hotkey to toggle amend/new
Hi Pratyush, On Tue, Sep 3, 2019 at 2:45 PM Pratyush Yadav wrote: > Can you try doing a Shift+Tab? For me on Linux, if I hit Shift+Tab, it > immediately takes me to the "Amend last commit" option. Then I can press > space to select it and Tab again to get back to the commit message. It seems that Shift+Tab doesn't do anything (on Windows 10). Regardless, imo there should be a binding dedicated to toggle amend. > Also, since we are on this topic, how about making the "Amend last > commit" button a toggle instead? This would act as a "turn amend mode > on/off" button. Since "Amend last commit" and "New Commit" are mutually > exclusive, a single toggle to switch between those modes makes sense to > me. I assume you're talking about the button in the "Commit" dropdown menu. I agree, it could be just a single entry which is a toggle to enable/disable amending. And (above the commit message dialog) perhaps just a single checkbox; "Amend Last Commit". In other git GUIs (Git Cola and TortoiseGit) I see they're using just a single checkbox for this option. But maybe that is a slightly different topic, the hotkey behaviour would remain the same. > ... do you still feel the need for a dedicated binding for amends? How do you guys feel about it? So far it seems we're at two "yay" and one "nay". I really feel it is in the best interest of the git-gui project to implement this hotkey. And not just because it is my personal preference to have it :-) Birger
Re: feature request, git-gui: add hotkey to toggle amend/new
On 03/09/19 07:37AM, Birger Skogeng Pedersen wrote: > On Mon, Sep 2, 2019 at 10:15 PM Bert Wesarg > wrote: > > does Control-Tab works for traversal? > > > Bert, > > Control+Tab works for traversal, but as a means to toggle new/amend > it's very tedious. I have to press Ctrl+Tab 9 times to select "new" > and 10 times to select "Amend"(!). Then 1 or 2 more times to go back > to the input area. > I sincerely doubt that this is your preferred method of switching > between new/amend. At this point we're better of letting go of the > keyboard and use the mouse, which is what I'm trying to avoid. Can you try doing a Shift+Tab? For me on Linux, if I hit Shift+Tab, it immediately takes me to the "Amend last commit" option. Then I can press space to select it and Tab again to get back to the commit message. Also, since we are on this topic, how about making the "Amend last commit" button a toggle instead? This would act as a "turn amend mode on/off" button. Since "Amend last commit" and "New Commit" are mutually exclusive, a single toggle to switch between those modes makes sense to me. > > I think this is short enough, so that wasting a Letter is not > > justified here. > I (also) often amend commits, so having a hotkey for this is quite a > necessity imo. Assuming the above works for you, do you still feel the need for a dedicated binding for amends? -- Regards, Pratyush Yadav
Re: feature request, git-gui: add hotkey to toggle amend/new
David, On Tue, Sep 3, 2019 at 3:01 AM David wrote: > > On Tue, 3 Sep 2019 at 04:11, Bert Wesarg wrote: > > On Mon, Sep 2, 2019 at 6:25 PM Birger Skogeng Pedersen > > wrote: > > > On Sat, Aug 31, 2019 at 12:51 PM Birger Skogeng Pedersen > > > wrote: > > > > > In my pursuit to fully utilize git-gui with only using a keyboard, I > > > > suggest that there is a hotkey to toggle between selecting "New > > > > Commit" and "Amend Last Commit". > > Hi, thanks for maintaining and contributing to git and git-gui, it's a > great tool! > > > After focusing the commit message widget, you can focus the radio > > buttons with Tab/Shift+Tab and press Space. > > > I think this is short enough, so that wasting a Letter is not > > justified here. > > Ugh, may I express how unhappy I am to read that opinion from > the maintainer. I strongly disagree, please reconsider :( > > And I enthusiastically support this initial request for a single > hotkey to immediately toggle between "New Commit" and "Amend Last > Commit". And it should work regardless of wherever the cursor or > highlight is currently active. > > I have used git-gui for many years and I find this is actually the > most annoying and inconsistent aspect of its user interface. Sometimes > if one is lucky then "spacebar" will achieve it at startup or after > refresh, sometimes not. When I test here just now the suggested > tab/shift-tab/spacebar method, it does toggle but it also changes the > items in the staged changes list as an unwanted side effect. My > version says 0.20.0.8.gd000, but I have a few local patches (written > years ago) so sorry I am not testing with a version that you have, but > even so I wanted to report what I observed. > > If one is often amending commit messages as I do during large > interactive rebases, it is painful to have to do some kind of > context-sensitive multi-key dance just to change from "New Commit" to > "Amend Last Commit". Especially when every other operation has become > a single keystroke in my muscle memory. > > In my world it most definitely would not be "wasting a letter" to > implement this! It would instead be "OMG at last that got fixed for > everyone, hooray!" :D thanks for the input. Though I'm not the maintainer. Bert
Re: feature request, git-gui: add hotkey to toggle amend/new
On Mon, Sep 2, 2019 at 10:15 PM Bert Wesarg wrote: > does Control-Tab works for traversal? Bert, Control+Tab works for traversal, but as a means to toggle new/amend it's very tedious. I have to press Ctrl+Tab 9 times to select "new" and 10 times to select "Amend"(!). Then 1 or 2 more times to go back to the input area. I sincerely doubt that this is your preferred method of switching between new/amend. At this point we're better of letting go of the keyboard and use the mouse, which is what I'm trying to avoid. > I think this is short enough, so that wasting a Letter is not justified here. I (also) often amend commits, so having a hotkey for this is quite a necessity imo. Birger
Re: feature request, git-gui: add hotkey to toggle amend/new
On Tue, 3 Sep 2019 at 04:11, Bert Wesarg wrote: > On Mon, Sep 2, 2019 at 6:25 PM Birger Skogeng Pedersen > wrote: > > On Sat, Aug 31, 2019 at 12:51 PM Birger Skogeng Pedersen > > wrote: > > > In my pursuit to fully utilize git-gui with only using a keyboard, I > > > suggest that there is a hotkey to toggle between selecting "New > > > Commit" and "Amend Last Commit". Hi, thanks for maintaining and contributing to git and git-gui, it's a great tool! > After focusing the commit message widget, you can focus the radio > buttons with Tab/Shift+Tab and press Space. > I think this is short enough, so that wasting a Letter is not > justified here. Ugh, may I express how unhappy I am to read that opinion from the maintainer. I strongly disagree, please reconsider :( And I enthusiastically support this initial request for a single hotkey to immediately toggle between "New Commit" and "Amend Last Commit". And it should work regardless of wherever the cursor or highlight is currently active. I have used git-gui for many years and I find this is actually the most annoying and inconsistent aspect of its user interface. Sometimes if one is lucky then "spacebar" will achieve it at startup or after refresh, sometimes not. When I test here just now the suggested tab/shift-tab/spacebar method, it does toggle but it also changes the items in the staged changes list as an unwanted side effect. My version says 0.20.0.8.gd000, but I have a few local patches (written years ago) so sorry I am not testing with a version that you have, but even so I wanted to report what I observed. If one is often amending commit messages as I do during large interactive rebases, it is painful to have to do some kind of context-sensitive multi-key dance just to change from "New Commit" to "Amend Last Commit". Especially when every other operation has become a single keystroke in my muscle memory. In my world it most definitely would not be "wasting a letter" to implement this! It would instead be "OMG at last that got fixed for everyone, hooray!" :D
Re: feature request, git-gui: add hotkey to toggle amend/new
On Mon, Sep 2, 2019 at 10:12 PM Bert Wesarg wrote: > > On Mon, Sep 2, 2019 at 9:49 PM Birger Skogeng Pedersen > wrote: > > > > Hi Bert, > > > > > > On Mon, Sep 2, 2019 at 8:08 PM Bert Wesarg > > wrote: > > > I think with your "focus" patch, this is not needed anymore: > > > > > > After focusing the commit message widget, you can focus the radio > > > buttons with Tab/Shift+Tab and press Space. > > > > > > I think this is short enough, so that wasting a Letter is not justified > > > here. > > > > Pressing the Tab key while the commit message widget is focused > > inserts a tab in the commit message. does Control-Tab works for traversal? > > (Again, I'm on Windows so you might get different behaviour on Linux) > > > > If the Tab key acted like you suggested, I agree it would not be > > necessary with this a hotkey like this. > > can we try to figure this out, before going forward with anything else? > > Thanks. > > Bert > > > > > > > Best regards, > > Birger
Re: feature request, git-gui: add hotkey to toggle amend/new
On Mon, Sep 2, 2019 at 9:49 PM Birger Skogeng Pedersen wrote: > > Hi Bert, > > > On Mon, Sep 2, 2019 at 8:08 PM Bert Wesarg wrote: > > I think with your "focus" patch, this is not needed anymore: > > > > After focusing the commit message widget, you can focus the radio > > buttons with Tab/Shift+Tab and press Space. > > > > I think this is short enough, so that wasting a Letter is not justified > > here. > > Pressing the Tab key while the commit message widget is focused > inserts a tab in the commit message. > (Again, I'm on Windows so you might get different behaviour on Linux) > > If the Tab key acted like you suggested, I agree it would not be > necessary with this a hotkey like this. can we try to figure this out, before going forward with anything else? Thanks. Bert > > > Best regards, > Birger
Re: feature request, git-gui: add hotkey to toggle amend/new
Hi Bert, On Mon, Sep 2, 2019 at 8:08 PM Bert Wesarg wrote: > I think with your "focus" patch, this is not needed anymore: > > After focusing the commit message widget, you can focus the radio > buttons with Tab/Shift+Tab and press Space. > > I think this is short enough, so that wasting a Letter is not justified here. Pressing the Tab key while the commit message widget is focused inserts a tab in the commit message. (Again, I'm on Windows so you might get different behaviour on Linux) If the Tab key acted like you suggested, I agree it would not be necessary with this a hotkey like this. Best regards, Birger
Re: feature request, git-gui: add hotkey to toggle amend/new
Birger, On Mon, Sep 2, 2019 at 6:25 PM Birger Skogeng Pedersen wrote: > > I just now realized what a terrible suggestion CTRL+Z was. > I propose CTRL/CMD+E to toggle between amend/new commit. > > On Sat, Aug 31, 2019 at 12:51 PM Birger Skogeng Pedersen > wrote: > > > > In my pursuit to fully utilize git-gui with only using a keyboard, I > > suggest that there is a hotkey to toggle between selecting "New > > Commit" and "Amend Last Commit". > > > > Not sure which key-combination that fits this purpose best, but my > > suggestion is CTRL/CMD+Z. I think with your "focus" patch, this is not needed anymore: After focusing the commit message widget, you can focus the radio buttons with Tab/Shift+Tab and press Space. I think this is short enough, so that wasting a Letter is not justified here. Best, Bert > > > > Best regards, > > Birger
Re: feature request, git-gui: add hotkey to toggle amend/new
I just now realized what a terrible suggestion CTRL+Z was. I propose CTRL/CMD+E to toggle between amend/new commit. On Sat, Aug 31, 2019 at 12:51 PM Birger Skogeng Pedersen wrote: > > In my pursuit to fully utilize git-gui with only using a keyboard, I > suggest that there is a hotkey to toggle between selecting "New > Commit" and "Amend Last Commit". > > Not sure which key-combination that fits this purpose best, but my > suggestion is CTRL/CMD+Z. > > Best regards, > Birger
Re: [Feature Request] Option to make .git not read-only in cloned repos
On Fri, Aug 30, 2019 at 9:25 PM Junio C Hamano wrote: > > But between these two: > > $ git clone --no-read-only-file-in-git https://github.com/foo/bar > ...sightsee... > $ rm -r bar > > to avoid "f" in "rm -r", vs. > > $ git clone https://github.com/foo/bar > ...sightsee... > $ rm -rf bar > > to clone a repository you only have a tentive interest in just like > any other more permanent repositories, I am not sure how the former > is preferrable. I would permanently enable --no-read-only-file-in-git for all newly cloned repositories (via an alias, or .gitconfig if possible), so there would be no need to type it every time.
Re: [Feature Request] Option to make .git not read-only in cloned repos
Michal Suchánek writes: >> But requiring an additional single "f" when doing "rm -rf .git"? Is >> that realy too much of a hassle? The option "-f" is to allow people >> deal with an unusual situation, while preventing everyday use from >> doing something harmful unintendedly. And removing a cloned >> repository is an unusual situation that would not happen every day, >> no? > ... > I am not in this situation so often but indeed I sometimes clone > several repositories in a day to search for a patch or piece of code > and then don't need them anymore. Some people may be in such situation > more often or regularly. But between these two: $ git clone --no-read-only-file-in-git https://github.com/foo/bar ...sightsee... $ rm -r bar to avoid "f" in "rm -r", vs. $ git clone https://github.com/foo/bar ...sightsee... $ rm -rf bar to clone a repository you only have a tentive interest in just like any other more permanent repositories, I am not sure how the former is preferrable.
Re: [Feature Request] Option to make .git not read-only in cloned repos
On Fri, 30 Aug 2019 09:38:11 -0700 Junio C Hamano wrote: > Albert Vaca Cintora writes: > > > On Tue, Aug 27, 2019 at 9:35 PM Junio C Hamano wrote: > >> > >> Ah, your "rm" command needs to learn "-f" option, too, then? > > > > The whole point of this thread was to remove the need of -f forcing the > > removal. > > OK, I misunderstood what you wanted to do. > > If an implementation of Git were making everything under .git/ > read-only, including directories, then it is veriy much reasonable > to complain against such an implementation. The usual "I know I am > doing something unusual and forcing it" safety given by "rm -rf" is > not enough to remove such a clone, and user would need "chmod -R u+w" > beforehand to be able to remove---that is being unreasonably paranoid > in the name of protecting against mistakes. > > But requiring an additional single "f" when doing "rm -rf .git"? Is > that realy too much of a hassle? The option "-f" is to allow people > deal with an unusual situation, while preventing everyday use from > doing something harmful unintendedly. And removing a cloned > repository is an unusual situation that would not happen every day, > no? Not everyone's day. Some people's day, sure. I am not in this situation so often but indeed I sometimes clone several repositories in a day to search for a patch or piece of code and then don't need them anymore. Some people may be in such situation more often or regularly. That's why this request makes sense to me. Thanks Michal
Re: [Feature Request] Option to make .git not read-only in cloned repos
Albert Vaca Cintora writes: > On Tue, Aug 27, 2019 at 9:35 PM Junio C Hamano wrote: >> >> Ah, your "rm" command needs to learn "-f" option, too, then? > > The whole point of this thread was to remove the need of -f forcing the > removal. OK, I misunderstood what you wanted to do. If an implementation of Git were making everything under .git/ read-only, including directories, then it is veriy much reasonable to complain against such an implementation. The usual "I know I am doing something unusual and forcing it" safety given by "rm -rf" is not enough to remove such a clone, and user would need "chmod -R u+w" beforehand to be able to remove---that is being unreasonably paranoid in the name of protecting against mistakes. But requiring an additional single "f" when doing "rm -rf .git"? Is that realy too much of a hassle? The option "-f" is to allow people deal with an unusual situation, while preventing everyday use from doing something harmful unintendedly. And removing a cloned repository is an unusual situation that would not happen every day, no?
Re: [Feature Request] Option to make .git not read-only in cloned repos
On Tue, Aug 27, 2019 at 9:35 PM Junio C Hamano wrote: > > Ah, your "rm" command needs to learn "-f" option, too, then? The whole point of this thread was to remove the need of -f forcing the removal.
Re: [Feature Request] Option to make .git not read-only in cloned repos
Albert Vaca Cintora writes: > It "works" for some definition of work, but it asks for confirmation > for every file, which is a pain. I'm on Linux. Ah, your "rm" command needs to learn "-f" option, too, then?
Re: [Feature Request] Option to make .git not read-only in cloned repos
On Mon, Aug 26, 2019 at 08:42:56PM +0200, Albert Vaca Cintora wrote: > > Why don't you wrap your clone in a script that calls chmod -R u+w .git > > after the clone? This seems like a pretty trivial approach regardless of > > your workflow. This works in Linux, Mac, Windows (under cygwin-bash) and > > anything else POSIX-ish. > > > > Wrapping `git clone` should work as a workaround. Although if that > doesn't break anything... then why were those files read-only in the > first place? :) Those read-only object and pack files contain all the version history, and, therefore, are precious. Making them read-only can protect from accidental deletion. > The fact that, from a formal point of view, those files are immutable > doesn't seem to justify them being read-only (or, at least, doesn't > follow any convention): there are plenty of immutable files on any > system (eg: all binaries and libs, application assets like images and > icons, pid/lock files for daemons, etc.) that are not made read-only. None of those files are actually immutable: the next update will overwrite the binaries, libs, and assets, stopping the daemon will remove the pidfile. OTOH, Git's object and pack files are indeed immutable.
Re: [Feature Request] Option to make .git not read-only in cloned repos
On Mon, Aug 26, 2019 at 4:38 PM Junio C Hamano wrote: > > And directories (e.g. .git/objects/) are not made read-only for > obvious reasons. Read-only files inside a writeable directory can > be deleted just like read-write ones can be (iow, the "delete > permission" comes from the "write permission" of the containing > directory) so "rm -r .git" should "work" just fine (depending on the > definition of working, of course---it is discouraged to throw away > your work). > It "works" for some definition of work, but it asks for confirmation for every file, which is a pain. I'm on Linux. On Mon, Aug 26, 2019 at 4:27 PM Randall S. Becker wrote: > > Why don't you wrap your clone in a script that calls chmod -R u+w .git after > the clone? This seems like a pretty trivial approach regardless of your > workflow. This works in Linux, Mac, Windows (under cygwin-bash) and anything > else POSIX-ish. > Wrapping `git clone` should work as a workaround. Although if that doesn't break anything... then why were those files read-only in the first place? :) The fact that, from a formal point of view, those files are immutable doesn't seem to justify them being read-only (or, at least, doesn't follow any convention): there are plenty of immutable files on any system (eg: all binaries and libs, application assets like images and icons, pid/lock files for daemons, etc.) that are not made read-only. I can go with the workaround, but I'm still inclined to think this option should be built in into git. Albert
RE: [Feature Request] Option to make .git not read-only in cloned repos
On August 26, 2019 11:28 AM, Junio C Hamano wrote: > "Randall S. Becker" writes: > > >> Sometimes I clone a repo just to grep for an error string and then I > >> don't need it anymore, or I clone several repos until I find the one > >> that contains what I want and delete the rest. Sometimes I want to > >> write a patch for some software I don't develop regularly so I don't need > to keep a clone of it. > >> > >> In any case, it would be useful to know the reason those files are > >> read-only in the first place. Do you guys know who might know? > > > > Why don't you wrap your clone in a script that calls chmod -R u+w .git > > after the clone? This seems like a pretty trivial approach regardless > > of your workflow. This works in Linux, Mac, Windows (under > > cygwin-bash) and anything else POSIX-ish. > > But on anything POSIX-ish, is it a problem for some files (but not any > directory) in .git is made read-only? Not for me or anyone I personally support. As I suggested to Albert, wrapping a clone in a script with a chmod would solve the problem with minimal work. My own personal issue is convincing people not to clone for every topic branch, but that's unrelated.
Re: [Feature Request] Option to make .git not read-only in cloned repos
"Randall S. Becker" writes: >> Sometimes I clone a repo just to grep for an error string and then I don't >> need it anymore, or I clone several repos until I find the one that contains >> what I want and delete the rest. Sometimes I want to write a patch for some >> software I don't develop regularly so I don't need to keep a clone of it. >> >> In any case, it would be useful to know the reason those files are read-only >> in >> the first place. Do you guys know who might know? > > Why don't you wrap your clone in a script that calls chmod -R u+w > .git after the clone? This seems like a pretty trivial approach > regardless of your workflow. This works in Linux, Mac, Windows > (under cygwin-bash) and anything else POSIX-ish. But on anything POSIX-ish, is it a problem for some files (but not any directory) in .git is made read-only?
Re: [Feature Request] Option to make .git not read-only in cloned repos
Philip Oakley writes: > Surely (?), if we are considering our stored revisions to be > immutable, then removing the write bit is the right thing to do. > If I understand correctly (*) we don't separate the delete permission > from 'no-write' permissions, so the consequence will be that such > files are read-only. And directories (e.g. .git/objects/) are not made read-only for obvious reasons. Read-only files inside a writeable directory can be deleted just like read-write ones can be (iow, the "delete permission" comes from the "write permission" of the containing directory) so "rm -r .git" should "work" just fine (depending on the definition of working, of course---it is discouraged to throw away your work). Perhaps Windows filesystem or file manager application behave differently and tries to protect users from removing read-only files in read-write folders by mistake, or something? If that is what the thread is complaining about, I agree that's a bit unfortunate. Perhaps Windows port can implement "this is an immultable file---do not write into it" slightly differently in adjust_shared_perm()?
RE: [Feature Request] Option to make .git not read-only in cloned repos
On August 25, 2019 3:59 PM, Albert Vaca Cintora wrote: > To: Johannes Sixt > On Sun, Aug 25, 2019 at 7:54 PM Johannes Sixt wrote: > > > > Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora: > > > However, I'm sure that a large percentage of developers out there > > > will agree with me that having to use force (-f) to delete every > > > cloned repo is annoying, and even worse, it creates the bad habit of > > > always force-deleting everything. > > > > IMO, the bad habit is to delete cloned repositories all the time. If > > your workflow necessitates this, then you are doing something wrong. > > Maybe you have an X-Y-problem? > > > > -- Hannes > > There are plenty of valid workflows where one would delete a repo. > > What you suggest is like saying I shouldn't delete pictures from my camera, > because in that case I shouldn't have taken them in the first place. > > Sometimes I clone a repo just to grep for an error string and then I don't > need it anymore, or I clone several repos until I find the one that contains > what I want and delete the rest. Sometimes I want to write a patch for some > software I don't develop regularly so I don't need to keep a clone of it. > > In any case, it would be useful to know the reason those files are read-only > in > the first place. Do you guys know who might know? Why don't you wrap your clone in a script that calls chmod -R u+w .git after the clone? This seems like a pretty trivial approach regardless of your workflow. This works in Linux, Mac, Windows (under cygwin-bash) and anything else POSIX-ish.
Re: [Feature Request] Option to make .git not read-only in cloned repos
On 25/08/2019 20:58, Albert Vaca Cintora wrote: On Sun, Aug 25, 2019 at 7:54 PM Johannes Sixt wrote: Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora: However, I'm sure that a large percentage of developers out there will agree with me that having to use force (-f) to delete every cloned repo is annoying, and even worse, it creates the bad habit of always force-deleting everything. IMO, the bad habit is to delete cloned repositories all the time. If your workflow necessitates this, then you are doing something wrong. Maybe you have an X-Y-problem? -- Hannes There are plenty of valid workflows where one would delete a repo. What you suggest is like saying I shouldn't delete pictures from my camera, because in that case I shouldn't have taken them in the first place. Sometimes I clone a repo just to grep for an error string and then I don't need it anymore, or I clone several repos until I find the one that contains what I want and delete the rest. Sometimes I want to write a patch for some software I don't develop regularly so I don't need to keep a clone of it. In any case, it would be useful to know the reason those files are read-only in the first place. Do you guys know who might know? Albert Surely (?), if we are considering our stored revisions to be immutable, then removing the write bit is the right thing to do. If I understand correctly (*) we don't separate the delete permission from 'no-write' permissions, so the consequence will be that such files are read-only. Philip (*) I'm primarily a Windows user, so certain Linux nuances pass me by ;-). I simply delete the repo folder then click the gui dialog to agree to delete the r/o files. Simples.
Re: [Feature Request] Option to make .git not read-only in cloned repos
On Sun, Aug 25, 2019 at 7:54 PM Johannes Sixt wrote: > > Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora: > > However, I'm sure that a large percentage of developers out there will > > agree with me that having to use force (-f) to delete every cloned > > repo is annoying, and even worse, it creates the bad habit of always > > force-deleting everything. > > IMO, the bad habit is to delete cloned repositories all the time. If > your workflow necessitates this, then you are doing something wrong. > Maybe you have an X-Y-problem? > > -- Hannes There are plenty of valid workflows where one would delete a repo. What you suggest is like saying I shouldn't delete pictures from my camera, because in that case I shouldn't have taken them in the first place. Sometimes I clone a repo just to grep for an error string and then I don't need it anymore, or I clone several repos until I find the one that contains what I want and delete the rest. Sometimes I want to write a patch for some software I don't develop regularly so I don't need to keep a clone of it. In any case, it would be useful to know the reason those files are read-only in the first place. Do you guys know who might know? Albert
Re: [Feature Request] Option to make .git not read-only in cloned repos
Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora: > However, I'm sure that a large percentage of developers out there will > agree with me that having to use force (-f) to delete every cloned > repo is annoying, and even worse, it creates the bad habit of always > force-deleting everything. IMO, the bad habit is to delete cloned repositories all the time. If your workflow necessitates this, then you are doing something wrong. Maybe you have an X-Y-problem? -- Hannes
Re: [Feature Request] Option to make .git not read-only in cloned repos
On Sun, Aug 25, 2019 at 1:59 PM Kevin Daudt wrote: > > On Fri, Aug 23, 2019 at 10:43:45PM +0200, Albert Vaca Cintora wrote: > > Hi git folks, > > > > Honestly I'm not aware of the reason behind .git being read-only, but > > I'm sure there is one. > > > > However, I'm sure that a large percentage of developers out there will > > agree with me that having to use force (-f) to delete every cloned > > repo is annoying, and even worse, it creates the bad habit of always > > force-deleting everything. > > > > Would you find reasonable to add an option to keep .git writable on > > cloned repos? > > > > PS: I'm not subscribed to the list, so please CC me on replies. > > > > Thanks! > > Albert > > To clarify, you are probably referring to things like pack-files, which > are created read-only. Most files / directories in .git are writable. > > It think this is already quite old behavior and I could not find any > reference as to why this is done. Indeed, not all files in .git are read-only. I'm talking about those which are. On Sun, Aug 25, 2019 at 1:59 PM Kevin Daudt wrote: > > On Fri, Aug 23, 2019 at 10:43:45PM +0200, Albert Vaca Cintora wrote: > > Hi git folks, > > > > Honestly I'm not aware of the reason behind .git being read-only, but > > I'm sure there is one. > > > > However, I'm sure that a large percentage of developers out there will > > agree with me that having to use force (-f) to delete every cloned > > repo is annoying, and even worse, it creates the bad habit of always > > force-deleting everything. > > > > Would you find reasonable to add an option to keep .git writable on > > cloned repos? > > > > PS: I'm not subscribed to the list, so please CC me on replies. > > > > Thanks! > > Albert > > To clarify, you are probably referring to things like pack-files, which > are created read-only. Most files / directories in .git are writable. > > It think this is already quite old behavior and I could not find any > reference as to why this is done.
Re: [Feature Request] Option to make .git not read-only in cloned repos
On Fri, Aug 23, 2019 at 10:43:45PM +0200, Albert Vaca Cintora wrote: > Hi git folks, > > Honestly I'm not aware of the reason behind .git being read-only, but > I'm sure there is one. > > However, I'm sure that a large percentage of developers out there will > agree with me that having to use force (-f) to delete every cloned > repo is annoying, and even worse, it creates the bad habit of always > force-deleting everything. > > Would you find reasonable to add an option to keep .git writable on > cloned repos? > > PS: I'm not subscribed to the list, so please CC me on replies. > > Thanks! > Albert To clarify, you are probably referring to things like pack-files, which are created read-only. Most files / directories in .git are writable. It think this is already quite old behavior and I could not find any reference as to why this is done.
Re: Feature-request: git-bundle --quiet
On Mon, Aug 12, 2019 at 12:15:19PM +0200, Jacob Vosmaer wrote: > This is a tangent, but relevant: how do we feel about the fact that > 'git bundle create' does not perform CRC32 checks when copying data > out of an existing packfile? > > See > https://github.com/git/git/blob/v2.22.0/builtin/pack-objects.c#L2614-L2622 . > > I understand the rationale of "skip CRC32 when serving a fetch", > although I have no clue how much we gain from skipping it. But "pack > to stdout means fetch" isn't quite accurate, as it includes bundles. I don't recall it being discussed in the past. I think you could argue either way: - a bundle is just another form of object transfer, like a fetch, and so we don't need to be careful about bitrot. The receiver would notice it when it indexes the pack (as opposed to an on-disk repack, where we'll immediately delete the old copy, and really want to make sure we haven't just lost data). - because a bundle isn't interactive like a regular fetch, any bit errors may not be seen until much later when somebody reads the. At that point it may not be possible to go back to the original repo (in the extreme case of using a bundle as a backup, it may have been deleted entirely!). Depending on the cost of those checks (and I really doubt they are all _that_ expensive), it might make sense for bundles to err on the conservative side and do them. And if they are expensive, it should perhaps be made an option for people who know they are planning to store the bundle for a long time without reading it[1]. I agree that linking "skip CRC32" to "pack to stdout" is a bit hacky. It should be easy to add a new --check-crc32 option which defaults to "!pack_to_stdout" if not specified. -Peff [1] Of course bitrot in the original packfile is just one place this can go wrong. Depending how paranoid you want to be, it might be worth reading back the result before considering it a valid backup. That would catch some software bugs, as well as any bit corruption on the writing side. Doing a full index-pack is the most robust way there, but it's quite expensive. Just checking the SHA1 of the packfile itself would give pretty good protection against write errors, though you'd definitely want to couple it with CRC32 checks on the source (since Git would otherwise include the bad bits in its SHA1 checksum).
Re: Feature-request: git-bundle --quiet
This is a tangent, but relevant: how do we feel about the fact that 'git bundle create' does not perform CRC32 checks when copying data out of an existing packfile? See https://github.com/git/git/blob/v2.22.0/builtin/pack-objects.c#L2614-L2622 . I understand the rationale of "skip CRC32 when serving a fetch", although I have no clue how much we gain from skipping it. But "pack to stdout means fetch" isn't quite accurate, as it includes bundles. Best regards, Jacob Vosmaer GitLab, Inc. Best regards, Jacob Vosmaer GitLab, Inc. On Thu, Aug 8, 2019 at 12:42 PM Jeff King wrote: > > On Tue, Aug 06, 2019 at 07:19:11PM +, Robin H. Johnson wrote: > > > I started trying to make a stab at implementing this, but the code > > wasn't standing out for it. Hopefully somebody else has poked at it > > before: > > > > I'd like to have a --quiet option for git-bundle, such that only errors > > are sent to stderr, and not the packing progress. > > This seems like a reasonable thing to want. > > It looks like you'd have to teach cmd_bundle() to use parse_options(), > parse a quiet flag, and then pas that down to create_bundle(). Then it > would pass it along to write_pack_data(), which would decide whether to > pass "-q". > > That would allow: > > git bundle --quiet create foo.bundle ... > > -Peff
Re: Feature-request: git-bundle --quiet
On Tue, Aug 06, 2019 at 07:19:11PM +, Robin H. Johnson wrote: > I started trying to make a stab at implementing this, but the code > wasn't standing out for it. Hopefully somebody else has poked at it > before: > > I'd like to have a --quiet option for git-bundle, such that only errors > are sent to stderr, and not the packing progress. This seems like a reasonable thing to want. It looks like you'd have to teach cmd_bundle() to use parse_options(), parse a quiet flag, and then pas that down to create_bundle(). Then it would pass it along to write_pack_data(), which would decide whether to pass "-q". That would allow: git bundle --quiet create foo.bundle ... -Peff
Re: Feature request: Allow to update commit ID in messages when rebasing
Hello, Giuseppe Crinò writes: > On Thu, Apr 18, 2019 at 7:32 PM Jakub Narebski wrote: >> Well, what about limiting changes and rewriting only to the commits >> being rewritten by [interactive] rebase? I mean that we would rewrite >> "revert 01a9fe8" only if: >> >> a.) the commit with this message is undergoing rewrite >> b.) the commit 01a9fe8 is undergoing rewrite in the same command >> >> We could use the infrastructure from git-filter-branch for this. >> >> It is serious limitation, but that might be good enough for Giuseppe >> Crinò use case. > > In which case you need to change the ID of "revert 01a9fe8" _even if_ > 01a9fe8 is not involved in the rebase? Wouldn't be a solution to my > use-case an already complete solution? What I meant by "serious limitation" is that the condition a.) might mot hold true. You might be rebasing / rewriting the commit 01a9fe8, but there might be some commit not undergoing rewrite (for example one on a separate branch) that refers to the commit being rewritten, e.g. by including "revert 01a9fe8" in the commit message. We also need to assume that the commit referred to (i.e. 01a9fe8) is being rewritten earlier in sequence than referring commit (i.e. one with "revert 01a9fe8"). Regards, -- Jakub Narębski
Re: Feature request: Allow to update commit ID in messages when rebasing
On Thu, Apr 18, 2019 at 7:32 PM Jakub Narebski wrote: > Well, what about limiting changes and rewriting only to the commits > being rewritten by [interactive] rebase? I mean that we would rewrite > "revert 01a9fe8" only if: > > a.) the commit with this message is undergoing rewrite > b.) the commit 01a9fe8 is undergoing rewrite in the same command > > We could use the infrastructure from git-filter-branch for this. > > It is serious limitation, but that might be good enough for Giuseppe > Crinò use case. In which case you need to change the ID of "revert 01a9fe8" _even if_ 01a9fe8 is not involved in the rebase? Wouldn't be a solution to my use-case an already complete solution?
Re: Feature request: Allow to update commit ID in messages when rebasing
Wouldn't we need to extend this to cherry-pick, too? Suppose I do this: $ git log -2 --oneline --decorate foo abcd123456 (foo) Revert 123456 123456 Some useful commit for the future, but not now $ git checkout bar $ git cherry-pick foo^ foo $ git log -2 --oneline --decorate badc0ffee (bar) Revert 123456 babeface0 Some useful commit for the future, but not now Now when I rebase bar, the revert appears to be untwinned. Similar problems arise for other history modifying tools like filter-branch, fast-export, reposurgeon, bfg, etc. I guess we can use 'git patch-id' to see if the companion commit is still in our history, but this seems tenuous. Can we make it work anyway? On Thu, Apr 18, 2019 at 10:33 AM Jakub Narebski wrote: > > Junio C Hamano writes: > > Ævar Arnfjörð Bjarmason writes: > >> On Wed, Apr 17 2019, Giuseppe Crinò wrote: > >> > >>> The feature I'm asking is to add an extra-step during rebasing, > >>> checking whether there's a reference to a commit that's not going to > >>> be included in history and asks the user whether the heuristics is > >>> correct and if she wants to update those references. > >>> > >>> Scenario: it can happen for a commit message to contain the ID of an > >>> ancestor commit. A typical example is a commit with the message > >>> "revert 01a9fe8". If 01a9fe8 and the commit that reverts it are > >>> involved in a rebase the message "revert 01a9fe8" is no longer valid > >>> -- the old 01a9fe8 has now a different hash. This will most likely be > >>> ignored by the person who's rebasing but will let the other people > >>> reading history confused. > >> > >> This would be useful. Done properly we'd need some machinery/command to > >> extract the commit id parts from the free-text of the commit > >> message. That would be useful for other parts of git, e.g. as discussed > >> here: > >> https://public-inbox.org/git/xmqqvaxp9oyp@gitster.mtv.corp.google.com/ > > > > That's a helpful input. > > > > But in general we do not have an infrastructure to systematically > > keep track of "this commit was rewritten to produce that other > > commit", so even if a mention of an old/superseded commit can be > > identified reliably, there is no reliable source to rewrite it to > > the name of the corresponding commit in the new world. > > > > For that mapping, we'd need something like the "git change/evolve" > > Stefan Xenos was working on, which hasn't materialized. > > Well, what about limiting changes and rewriting only to the commits > being rewritten by [interactive] rebase? I mean that we would rewrite > "revert 01a9fe8" only if: > > a.) the commit with this message is undergoing rewrite > b.) the commit 01a9fe8 is undergoing rewrite in the same command > > We could use the infrastructure from git-filter-branch for this. > > It is serious limitation, but that might be good enough for Giuseppe > Crinò use case. Though for example there is a question what to do if > referred-to commit (01a9fe8 in the example) is simply dropped, or is > gets split in two? Ask user? > > > Another possibility would be to provide a command line option to rebase > which would automatically generate replacements (in git-replace meaning) > from old pre-rebase name to new post-rebase name (assuming no splitting, > no dropping commits). This would make references just work... well, as > long as refs/replace/* are in place (they are not copied by default). > > On the other hand some of our performance-improving features, like the > commit-graph, do not work if there are replacements. > > > Best, > -- > Jakub Narębski
Re: Feature request: Allow to update commit ID in messages when rebasing
Junio C Hamano writes: > Ævar Arnfjörð Bjarmason writes: >> On Wed, Apr 17 2019, Giuseppe Crinò wrote: >> >>> The feature I'm asking is to add an extra-step during rebasing, >>> checking whether there's a reference to a commit that's not going to >>> be included in history and asks the user whether the heuristics is >>> correct and if she wants to update those references. >>> >>> Scenario: it can happen for a commit message to contain the ID of an >>> ancestor commit. A typical example is a commit with the message >>> "revert 01a9fe8". If 01a9fe8 and the commit that reverts it are >>> involved in a rebase the message "revert 01a9fe8" is no longer valid >>> -- the old 01a9fe8 has now a different hash. This will most likely be >>> ignored by the person who's rebasing but will let the other people >>> reading history confused. >> >> This would be useful. Done properly we'd need some machinery/command to >> extract the commit id parts from the free-text of the commit >> message. That would be useful for other parts of git, e.g. as discussed >> here: >> https://public-inbox.org/git/xmqqvaxp9oyp@gitster.mtv.corp.google.com/ > > That's a helpful input. > > But in general we do not have an infrastructure to systematically > keep track of "this commit was rewritten to produce that other > commit", so even if a mention of an old/superseded commit can be > identified reliably, there is no reliable source to rewrite it to > the name of the corresponding commit in the new world. > > For that mapping, we'd need something like the "git change/evolve" > Stefan Xenos was working on, which hasn't materialized. Well, what about limiting changes and rewriting only to the commits being rewritten by [interactive] rebase? I mean that we would rewrite "revert 01a9fe8" only if: a.) the commit with this message is undergoing rewrite b.) the commit 01a9fe8 is undergoing rewrite in the same command We could use the infrastructure from git-filter-branch for this. It is serious limitation, but that might be good enough for Giuseppe Crinò use case. Though for example there is a question what to do if referred-to commit (01a9fe8 in the example) is simply dropped, or is gets split in two? Ask user? Another possibility would be to provide a command line option to rebase which would automatically generate replacements (in git-replace meaning) from old pre-rebase name to new post-rebase name (assuming no splitting, no dropping commits). This would make references just work... well, as long as refs/replace/* are in place (they are not copied by default). On the other hand some of our performance-improving features, like the commit-graph, do not work if there are replacements. Best, -- Jakub Narębski
Re: Feature request: Allow to update commit ID in messages when rebasing
Ævar Arnfjörð Bjarmason writes: > On Wed, Apr 17 2019, Giuseppe Crinò wrote: > >> The feature I'm asking is to add an extra-step during rebasing, >> checking whether there's a reference to a commit that's not going to >> be included in history and asks the user whether the heuristics is >> correct and if she wants to update those references. >> >> Scenario: it can happen for a commit message to contain the ID of an >> ancestor commit. A typical example is a commit with the message >> "revert 01a9fe8". If 01a9fe8 and the commit that reverts it are >> involved in a rebase the message "revert 01a9fe8" is no longer valid >> -- the old 01a9fe8 has now a different hash. This will most likely be >> ignored by the person who's rebasing but will let the other people >> reading history confused. > > This would be useful. Done properly we'd need some machinery/command to > extract the commit id parts from the free-text of the commit > message. That would be useful for other parts of git, e.g. as discussed > here: > https://public-inbox.org/git/xmqqvaxp9oyp@gitster.mtv.corp.google.com/ That's a helpful input. But in general we do not have an infrastructure to systematically keep track of "this commit was rewritten to produce that other commit", so even if a mention of an old/superseded commit can be identified reliably, there is no reliable source to rewrite it to the name of the corresponding commit in the new world. For that mapping, we'd need something like the "git change/evolve" Stefan Xenos was working on, which hasn't materialized.
Re: Feature request: Allow to update commit ID in messages when rebasing
On Wed, Apr 17 2019, Giuseppe Crinò wrote: > The feature I'm asking is to add an extra-step during rebasing, > checking whether there's a reference to a commit that's not going to > be included in history and asks the user whether the heuristics is > correct and if she wants to update those references. > > Scenario: it can happen for a commit message to contain the ID of an > ancestor commit. A typical example is a commit with the message > "revert 01a9fe8". If 01a9fe8 and the commit that reverts it are > involved in a rebase the message "revert 01a9fe8" is no longer valid > -- the old 01a9fe8 has now a different hash. This will most likely be > ignored by the person who's rebasing but will let the other people > reading history confused. This would be useful. Done properly we'd need some machinery/command to extract the commit id parts from the free-text of the commit message. That would be useful for other parts of git, e.g. as discussed here: https://public-inbox.org/git/xmqqvaxp9oyp@gitster.mtv.corp.google.com/
Re: feature request: .blameignore
> I think there's a slight misunderstanding. In the patchset that > Michael and I are working on, the user specifies whole commits > explicitly. This is usually done with a file, but can also be done > from the command line for "one-off" ignored commits. That sounds like > what you want. > > The heuristics come in when we try to pass blame for specific *lines* > that an ignored commit touched. We pass the blame to the parent > commit, but we also want to match the lines to a specific line in the > parent commit. That way we can find the 'right' ancestor commmit. > We're not able to always identify the 'right' commit, hence the > heuristics. > Oh - that's something different, yes - thank you for clarifying! Misunderstanding on my side, yes. This is a really great feature! Is there a vague time schedule for a release? Still this year? Thanks! Christian pEpkey.asc Description: application/pgp-keys
Re: feature request: .blameignore
Hi - On 4/15/19 5:56 PM, Christian González wrote: Am 15.04.19 um 23:15 schrieb Thomas Gummerer: This sounds roughly like what Barret Rhoden (added to Cc) has been working on. I haven't followed that patch series in detail, but you can have a look at it atthe latest iteration at https://public-inbox.org/git/20190410162409.117264-1-b...@google.com/. As far as I can see this is an "automagic" way of creating those "blame skips" - which can be easier in some way, but until it works "perfect" It is prone to produce problems IMHO. The git history is a "document" that _has_ not to be changed by design. So if this "heuristic" produces a wrong result, it's kind of unpredictable what was wrong. I think it would be MUCH easier to mark chunks or whole commits as "not important" explicitly - by using a file. I think there's a slight misunderstanding. In the patchset that Michael and I are working on, the user specifies whole commits explicitly. This is usually done with a file, but can also be done from the command line for "one-off" ignored commits. That sounds like what you want. The heuristics come in when we try to pass blame for specific *lines* that an ignored commit touched. We pass the blame to the parent commit, but we also want to match the lines to a specific line in the parent commit. That way we can find the 'right' ancestor commmit. We're not able to always identify the 'right' commit, hence the heuristics. Barret
Re: feature request: .blameignore
Am 15.04.19 um 23:15 schrieb Thomas Gummerer: > This sounds roughly like what Barret Rhoden (added to Cc) has been > working on. I haven't followed that patch series in detail, but you > can have a look at it atthe latest iteration at > https://public-inbox.org/git/20190410162409.117264-1-b...@google.com/. As far as I can see this is an "automagic" way of creating those "blame skips" - which can be easier in some way, but until it works "perfect" It is prone to produce problems IMHO. The git history is a "document" that _has_ not to be changed by design. So if this "heuristic" produces a wrong result, it's kind of unpredictable what was wrong. I think it would be MUCH easier to mark chunks or whole commits as "not important" explicitly - by using a file. Look at .gitignore: git isn't trying to heuristically determine which files should be ignored when committing. This is done explicitly in a .gitignore file. For blames this could be done too. Heuristics could lead to other kind of problems too, as the engine does not know anything about the project. Maybe there will be a programming language in near future where trailing whitespaces matter (bah, please not). But the project should decide, not git itself. So IMHO project specific .*ignore files are the better way of handling this than doing the skipping on heuristics alone - which could be helpful though when *creating* that files, even during the commit process... like git ccheckut git: 'ccheckut' is not a git command. See 'git --help'. The most similar command is checkout Maybe a lazy: git commit -a -m "big, clunky, fixes everything and the rest" could produce a message like: There are whitespace changes in files , ... - git automatically marked them as not important commits. They are ignored when using git-blame. Christian -- Dr. Christian González https://nerdocs.at pEpkey.asc Description: application/pgp-keys
Re: feature request: .blameignore
On 04/15, Christian González wrote: > Hello git community, > > I'm completely new here, and maybe my request is dumb, has already a > better solution, or I did not fully understand git. Please tell my if > so. I stumbled upon this idea while following the django developers > mailing list, people there discussing whether nor not to adopt *black* > (https://github.com/ambv/black, a python code formatting tool) as > enhancement in the development cycle. One of the main arguments against > black was that it changes git history by masking git blame. Whenever a > git commit with only a black formatting change is committed, you can't > easily see using git blame WHO did actially write a line of code > *before* that commit. It is possible to look further manually, and they > said there are tools like git-hyper-blame that circumvent that problem, > but I always asked myself since I use git, why isn't there a simple > possibility how I can e.g. fix a whitespace code "error", or do a code > reformatting WITHOUT taking away the original author's credits for that > line. > > I know, there are some counter arguments about that: e.g. whitespace > changes could lead to programming errors too, even to compiler errors, > depending on the language, and how the compiler engine treats whitespace. > > I don't suggest git to ignore whitespace (or whatever) changes in the > blame history automatically. > > What I suggest is: let git accept a file like .blameignore, > .gitblameignore, .gitblame etc., you name it. > In my simply suggest, I would see that file as one-hash-per-line that is > ignored by git blame. And for the sake of convenience, add a git option > to add that hash automatically: This sounds roughly like what Barret Rhoden (added to Cc) has been working on. I haven't followed that patch series in detail, but you can have a look at it atthe latest iteration at https://public-inbox.org/git/20190410162409.117264-1-b...@google.com/. > git commit -m "fix whitespace" --blame-ignore > > This would add this commit's hash to the .gitblameignore (or whatever) file: > > 4070ddcdd3d3cc45ec7952e1b37ab374aed9083c # fix whitespace > > and a "git blame any_file.txt" would ignore this one commit and show the > last commit's author of changed lines. > > Even better would it be to allow chunks to be excluded, because bad > commit habits of whitespace AND real code changes at the same time are > not possible to undo later - except there would be a .gitblameignore file. > > It would even be possible to incorporate this into tht .gitignore file, > with a section, or a certain prefix... > > IMHO, this would allow better per-project maintainance of blame history > which could be changed later in time and re-fixed if done wrong - all > within git history itself. > > I'd love to hear what you think about that. > > Yours, > > Christian > > > > -- > Dr. Christian González > https://nerdocs.at > +43 (0) 650 7644477 > [-- Error: unable to create PGP subprocess! --]
Re: Feature request: Add --no-edit to git tag command
On Fri, Apr 12, 2019 at 11:32:25AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > On Thu, Apr 11, 2019 at 03:20:52PM -0300, Bárbara de Castro Fernandes wrote: > > > >> This new proposed --amend option, although semantically different, > >> would have a very similar functionality to the already existing -f > >> option. So should we, perhaps, change -f's behavior to treat the tag > >> as a new one, treating the old one as if it never existed (as I think > >> Junio was saying)? By this I mean the command should fail if the user > >> doesn't give a SHA-1 and the previous message wouldn't be preloaded. > >> --amend, on the other hand, would give the user an opportunity to > >> revise the tag by opening, by default, the editor with the > >> pre-existing message unless given the '--no-edit' option, and if not > >> given a SHA-1 it would keep on using the previous one. > > > > Yes, that's what I'd expect it to do (so yes, it's also different from > > "-f" in that it defaults to the existing tag destination instead of > > HEAD). > > Do you mean you'd expect "--amend" to do that, which is different > from what "-f" does, so they should not be conflated into one? > > If so, I think that makes sense and changing the behaviour of "-f" > is too confusing. Yes, sorry to be unclear. The "it" in my sentence was "--amend". -Peff
Re: Feature request: Add --no-edit to git tag command
Jeff King writes: > On Thu, Apr 11, 2019 at 03:20:52PM -0300, Bárbara de Castro Fernandes wrote: > >> This new proposed --amend option, although semantically different, >> would have a very similar functionality to the already existing -f >> option. So should we, perhaps, change -f's behavior to treat the tag >> as a new one, treating the old one as if it never existed (as I think >> Junio was saying)? By this I mean the command should fail if the user >> doesn't give a SHA-1 and the previous message wouldn't be preloaded. >> --amend, on the other hand, would give the user an opportunity to >> revise the tag by opening, by default, the editor with the >> pre-existing message unless given the '--no-edit' option, and if not >> given a SHA-1 it would keep on using the previous one. > > Yes, that's what I'd expect it to do (so yes, it's also different from > "-f" in that it defaults to the existing tag destination instead of > HEAD). Do you mean you'd expect "--amend" to do that, which is different from what "-f" does, so they should not be conflated into one? If so, I think that makes sense and changing the behaviour of "-f" is too confusing.
Re: Feature request: Add --no-edit to git tag command
On Thu, Apr 11, 2019 at 03:20:52PM -0300, Bárbara de Castro Fernandes wrote: > This new proposed --amend option, although semantically different, > would have a very similar functionality to the already existing -f > option. So should we, perhaps, change -f's behavior to treat the tag > as a new one, treating the old one as if it never existed (as I think > Junio was saying)? By this I mean the command should fail if the user > doesn't give a SHA-1 and the previous message wouldn't be preloaded. > --amend, on the other hand, would give the user an opportunity to > revise the tag by opening, by default, the editor with the > pre-existing message unless given the '--no-edit' option, and if not > given a SHA-1 it would keep on using the previous one. Yes, that's what I'd expect it to do (so yes, it's also different from "-f" in that it defaults to the existing tag destination instead of HEAD). -Peff
Re: Feature request: Add --no-edit to git tag command
Em sex, 5 de abr de 2019 às 19:21, Jeff King escreveu: > > On Thu, Apr 04, 2019 at 08:56:16AM -0500, Robert Dailey wrote: > > > > I was thinking it was just the --no-edit fix. :) Even with the "--amend" > > > thing, though, it's probably a little light for a 3-month-long GSoC > > > project. :) > > > > I apologize for the confusion. I'm not fully aware of any per-option > > philosophies in Git, so I may be unaware of the misunderstanding my > > request is causing. Let me attempt to clarify. > > I think most of the confusion was just bad reading on my part. :) > > > My goal as a user is to correct a tag. If I point a tag at the wrong > > commit, I simply want to move that tag to point to another commit. At > > the moment, the only way I know to do this is the -f option, which I > > just treat as a "move" for the tag. I realize that may not be its > > intent in the implementation, but from a user perspective that's the > > end result I get. > > > > So if I treat -f as a "move this tag", I also want to say "reuse the > > existing commit message". So again, in my mind, that means -f > > --no-edit. Which means "I'm moving this tag and I want to keep the > > previous commit message". > > > > I hope this makes more sense. If getting this means not using -f or > > --no-edit at all, and is instead a whole different set of options, I'm > > OK with that as long as the end result is achievable. It's impossible > > to write a script to "move" (-f) a bunch of annotated tags without an > > editor prompting me on each one. So this "--no-edit" addition would > > assist in automation, and also making sure that we simply want to > > correct a tag, but not alter the message. > > Yeah, I think what you want to do is perfectly reasonable. The only > reason not to use "-f" is because it already means other things, and we > don't want to overload it. This new proposed --amend option, although semantically different, would have a very similar functionality to the already existing -f option. So should we, perhaps, change -f's behavior to treat the tag as a new one, treating the old one as if it never existed (as I think Junio was saying)? By this I mean the command should fail if the user doesn't give a SHA-1 and the previous message wouldn't be preloaded. --amend, on the other hand, would give the user an opportunity to revise the tag by opening, by default, the editor with the pre-existing message unless given the '--no-edit' option, and if not given a SHA-1 it would keep on using the previous one. > Calling it "--amend" would make perfect > sense (and then fixing "--no-edit" so it lets you avoid opening the > editor). So I think there are two bits of work: > > 1. Add an "--amend" option, which allows overwriting an existing tag > and pre-populates the message with the existing tag's message. > > 2. Make --no-edit work like the patch I showed earlier (assuming that > your --amend still opens an editor by default). > > -Peff
Re: Feature request: Add --no-edit to git tag command
On Thu, Apr 04, 2019 at 08:56:16AM -0500, Robert Dailey wrote: > > I was thinking it was just the --no-edit fix. :) Even with the "--amend" > > thing, though, it's probably a little light for a 3-month-long GSoC > > project. :) > > I apologize for the confusion. I'm not fully aware of any per-option > philosophies in Git, so I may be unaware of the misunderstanding my > request is causing. Let me attempt to clarify. I think most of the confusion was just bad reading on my part. :) > My goal as a user is to correct a tag. If I point a tag at the wrong > commit, I simply want to move that tag to point to another commit. At > the moment, the only way I know to do this is the -f option, which I > just treat as a "move" for the tag. I realize that may not be its > intent in the implementation, but from a user perspective that's the > end result I get. > > So if I treat -f as a "move this tag", I also want to say "reuse the > existing commit message". So again, in my mind, that means -f > --no-edit. Which means "I'm moving this tag and I want to keep the > previous commit message". > > I hope this makes more sense. If getting this means not using -f or > --no-edit at all, and is instead a whole different set of options, I'm > OK with that as long as the end result is achievable. It's impossible > to write a script to "move" (-f) a bunch of annotated tags without an > editor prompting me on each one. So this "--no-edit" addition would > assist in automation, and also making sure that we simply want to > correct a tag, but not alter the message. Yeah, I think what you want to do is perfectly reasonable. The only reason not to use "-f" is because it already means other things, and we don't want to overload it. Calling it "--amend" would make perfect sense (and then fixing "--no-edit" so it lets you avoid opening the editor). So I think there are two bits of work: 1. Add an "--amend" option, which allows overwriting an existing tag and pre-populates the message with the existing tag's message. 2. Make --no-edit work like the patch I showed earlier (assuming that your --amend still opens an editor by default). -Peff
Re: Feature request: Add --no-edit to git tag command
On Thu, Apr 4, 2019 at 8:56 AM Robert Dailey wrote:
>
> On Thu, Apr 4, 2019 at 7:06 AM Jeff King wrote:
> >
> > On Wed, Apr 03, 2019 at 08:26:06PM -0700, Taylor Blau wrote:
> >
> > > Agreed.
> > >
> > > I think that the implement is a little different than "add a --no-edit"
> > > flag, though. 'git tag' already has a OPT_BOOL for '--edit', which means
> > > that '--no-edit' exists, too.
> > >
> > > But, when we look and see how the edit option is passed around, we find
> > > that the check whether or not to launch the editor (again, in
> > > builtin/tag.c within 'create_tag()') is:
> > >
> > > if (!opt->message_given || opt->use_editor)
> > >
> > > So, it's not that we didn't take '--no-edit', it's that we didn't get a
> > > _message_, so we'll open the editor to get one (even if '--no-edit' was
> > > given).
> >
> > Yeah, I think the fundamental issue with --no-edit is that it is not a
> > tristate, so we cannot tell the difference between --edit, --no-edit,
> > and nothing.
> >
> > I think regardless of the "re-use message bits", we'd want something
> > like:
> >
> > diff --git a/builtin/tag.c b/builtin/tag.c
> > index 02f6bd1279..260adcaa60 100644
> > --- a/builtin/tag.c
> > +++ b/builtin/tag.c
> > @@ -196,7 +196,7 @@ static int build_tag_object(struct strbuf *buf, int
> > sign, struct object_id *resu
> >
> > struct create_tag_options {
> > unsigned int message_given:1;
> > - unsigned int use_editor:1;
> > + int use_editor;
> > unsigned int sign;
> > enum {
> > CLEANUP_NONE,
> > @@ -227,7 +227,7 @@ static void create_tag(const struct object_id *object,
> > const char *tag,
> > tag,
> > git_committer_info(IDENT_STRICT));
> >
> > - if (!opt->message_given || opt->use_editor) {
> > + if ((!opt->message_given && opt->use_editor != 0) ||
> > opt->use_editor > 0) {
> > int fd;
> >
> > /* write the template message before editing: */
> > @@ -380,7 +380,7 @@ int cmd_tag(int argc, const char **argv, const char
> > *prefix)
> > static struct ref_sorting *sorting = NULL, **sorting_tail =
> > &sorting;
> > struct ref_format format = REF_FORMAT_INIT;
> > int icase = 0;
> > - int edit_flag = 0;
> > + int edit_flag = -1;
> > struct option options[] = {
> > OPT_CMDMODE('l', "list", &cmdmode, N_("list tag names"),
> > 'l'),
> > { OPTION_INTEGER, 'n', NULL, &filter.lines, N_("n"),
> >
> > which even does the right thing with "git tag --no-edit -a foo" (it dies
> > with "fatal: no tag message?"
> >
> > > This makes me think that we should do two things:
> > >
> > > 1. Make !opt->message_give && !opt->use_editor an invalid invocation.
> > > If I (1) didn't give a message but I did (2) give '--no-edit', I'd
> > > expect a complaint, not an editor window.
> > >
> > > 2. Then, do what Robert suggests, which is to "make opt->message_given
> > > true", by re-using the previous tag's message.
> >
> > I think I misunderstood Robert's proposal. I thought it was just about
> > fixing --no-edit, but it's actually about _adding_ (2). Which I think
> > we'd want to do differently. See Junio's reply elsewhere in the thread
> > (and my reply there).
> >
> > > > I think it wouldn't be very hard to implement, either. Maybe a good
> > > > starter project or #leftoverbits for somebody.
> > >
> > > Maybe. I think that it's made a little more complicated by the above,
> > > but it's certainly doable. Maybe good for GSoC?
> >
> > I was thinking it was just the --no-edit fix. :) Even with the "--amend"
> > thing, though, it's probably a little light for a 3-month-long GSoC
> > project. :)
>
> I apologize for the confusion. I'm not fully aware of any per-option
> philosophies in Git, so I may be unaware of the misunderstanding my
> request is causing. Let me attempt to clarify.
>
> My goal as a user is to correct a tag. If I point a tag at the wrong
> commit, I simply want to move that tag to point to another commit. At
> the moment, the only way I know to do this is the -f option, which I
> just treat as a "move" for the tag. I realize that may not be its
> intent in the implementation, but from a user perspective that's the
> end result I get.
>
> So if I treat -f as a "move this tag", I also want to say "reuse the
> existing commit message". So again, in my mind, that means -f
> --no-edit. Which means "I'm moving this tag and I want to keep the
> previous commit message".
>
> I hope this makes more sense. If getting this means not using -f or
> --no-edit at all, and is instead a whole different set of options, I'm
> OK with that as long as the end result is achievable. It's impossible
> to write a script to "move" (-f) a bunch of annotated tags without an
> editor prompting me on each one. So this "--no-edit" addition would
> assist in automation, and also making sure that we simply want to
> correct a ta
Re: Feature request: Add --no-edit to git tag command
On Thu, Apr 4, 2019 at 7:06 AM Jeff King wrote:
>
> On Wed, Apr 03, 2019 at 08:26:06PM -0700, Taylor Blau wrote:
>
> > Agreed.
> >
> > I think that the implement is a little different than "add a --no-edit"
> > flag, though. 'git tag' already has a OPT_BOOL for '--edit', which means
> > that '--no-edit' exists, too.
> >
> > But, when we look and see how the edit option is passed around, we find
> > that the check whether or not to launch the editor (again, in
> > builtin/tag.c within 'create_tag()') is:
> >
> > if (!opt->message_given || opt->use_editor)
> >
> > So, it's not that we didn't take '--no-edit', it's that we didn't get a
> > _message_, so we'll open the editor to get one (even if '--no-edit' was
> > given).
>
> Yeah, I think the fundamental issue with --no-edit is that it is not a
> tristate, so we cannot tell the difference between --edit, --no-edit,
> and nothing.
>
> I think regardless of the "re-use message bits", we'd want something
> like:
>
> diff --git a/builtin/tag.c b/builtin/tag.c
> index 02f6bd1279..260adcaa60 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -196,7 +196,7 @@ static int build_tag_object(struct strbuf *buf, int sign,
> struct object_id *resu
>
> struct create_tag_options {
> unsigned int message_given:1;
> - unsigned int use_editor:1;
> + int use_editor;
> unsigned int sign;
> enum {
> CLEANUP_NONE,
> @@ -227,7 +227,7 @@ static void create_tag(const struct object_id *object,
> const char *tag,
> tag,
> git_committer_info(IDENT_STRICT));
>
> - if (!opt->message_given || opt->use_editor) {
> + if ((!opt->message_given && opt->use_editor != 0) || opt->use_editor
> > 0) {
> int fd;
>
> /* write the template message before editing: */
> @@ -380,7 +380,7 @@ int cmd_tag(int argc, const char **argv, const char
> *prefix)
> static struct ref_sorting *sorting = NULL, **sorting_tail = &sorting;
> struct ref_format format = REF_FORMAT_INIT;
> int icase = 0;
> - int edit_flag = 0;
> + int edit_flag = -1;
> struct option options[] = {
> OPT_CMDMODE('l', "list", &cmdmode, N_("list tag names"), 'l'),
> { OPTION_INTEGER, 'n', NULL, &filter.lines, N_("n"),
>
> which even does the right thing with "git tag --no-edit -a foo" (it dies
> with "fatal: no tag message?"
>
> > This makes me think that we should do two things:
> >
> > 1. Make !opt->message_give && !opt->use_editor an invalid invocation.
> > If I (1) didn't give a message but I did (2) give '--no-edit', I'd
> > expect a complaint, not an editor window.
> >
> > 2. Then, do what Robert suggests, which is to "make opt->message_given
> > true", by re-using the previous tag's message.
>
> I think I misunderstood Robert's proposal. I thought it was just about
> fixing --no-edit, but it's actually about _adding_ (2). Which I think
> we'd want to do differently. See Junio's reply elsewhere in the thread
> (and my reply there).
>
> > > I think it wouldn't be very hard to implement, either. Maybe a good
> > > starter project or #leftoverbits for somebody.
> >
> > Maybe. I think that it's made a little more complicated by the above,
> > but it's certainly doable. Maybe good for GSoC?
>
> I was thinking it was just the --no-edit fix. :) Even with the "--amend"
> thing, though, it's probably a little light for a 3-month-long GSoC
> project. :)
I apologize for the confusion. I'm not fully aware of any per-option
philosophies in Git, so I may be unaware of the misunderstanding my
request is causing. Let me attempt to clarify.
My goal as a user is to correct a tag. If I point a tag at the wrong
commit, I simply want to move that tag to point to another commit. At
the moment, the only way I know to do this is the -f option, which I
just treat as a "move" for the tag. I realize that may not be its
intent in the implementation, but from a user perspective that's the
end result I get.
So if I treat -f as a "move this tag", I also want to say "reuse the
existing commit message". So again, in my mind, that means -f
--no-edit. Which means "I'm moving this tag and I want to keep the
previous commit message".
I hope this makes more sense. If getting this means not using -f or
--no-edit at all, and is instead a whole different set of options, I'm
OK with that as long as the end result is achievable. It's impossible
to write a script to "move" (-f) a bunch of annotated tags without an
editor prompting me on each one. So this "--no-edit" addition would
assist in automation, and also making sure that we simply want to
correct a tag, but not alter the message.
Re: Feature request: Add --no-edit to git tag command
On Wed, Apr 03, 2019 at 08:26:06PM -0700, Taylor Blau wrote:
> Agreed.
>
> I think that the implement is a little different than "add a --no-edit"
> flag, though. 'git tag' already has a OPT_BOOL for '--edit', which means
> that '--no-edit' exists, too.
>
> But, when we look and see how the edit option is passed around, we find
> that the check whether or not to launch the editor (again, in
> builtin/tag.c within 'create_tag()') is:
>
> if (!opt->message_given || opt->use_editor)
>
> So, it's not that we didn't take '--no-edit', it's that we didn't get a
> _message_, so we'll open the editor to get one (even if '--no-edit' was
> given).
Yeah, I think the fundamental issue with --no-edit is that it is not a
tristate, so we cannot tell the difference between --edit, --no-edit,
and nothing.
I think regardless of the "re-use message bits", we'd want something
like:
diff --git a/builtin/tag.c b/builtin/tag.c
index 02f6bd1279..260adcaa60 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -196,7 +196,7 @@ static int build_tag_object(struct strbuf *buf, int sign,
struct object_id *resu
struct create_tag_options {
unsigned int message_given:1;
- unsigned int use_editor:1;
+ int use_editor;
unsigned int sign;
enum {
CLEANUP_NONE,
@@ -227,7 +227,7 @@ static void create_tag(const struct object_id *object,
const char *tag,
tag,
git_committer_info(IDENT_STRICT));
- if (!opt->message_given || opt->use_editor) {
+ if ((!opt->message_given && opt->use_editor != 0) || opt->use_editor >
0) {
int fd;
/* write the template message before editing: */
@@ -380,7 +380,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
static struct ref_sorting *sorting = NULL, **sorting_tail = &sorting;
struct ref_format format = REF_FORMAT_INIT;
int icase = 0;
- int edit_flag = 0;
+ int edit_flag = -1;
struct option options[] = {
OPT_CMDMODE('l', "list", &cmdmode, N_("list tag names"), 'l'),
{ OPTION_INTEGER, 'n', NULL, &filter.lines, N_("n"),
which even does the right thing with "git tag --no-edit -a foo" (it dies
with "fatal: no tag message?"
> This makes me think that we should do two things:
>
> 1. Make !opt->message_give && !opt->use_editor an invalid invocation.
> If I (1) didn't give a message but I did (2) give '--no-edit', I'd
> expect a complaint, not an editor window.
>
> 2. Then, do what Robert suggests, which is to "make opt->message_given
> true", by re-using the previous tag's message.
I think I misunderstood Robert's proposal. I thought it was just about
fixing --no-edit, but it's actually about _adding_ (2). Which I think
we'd want to do differently. See Junio's reply elsewhere in the thread
(and my reply there).
> > I think it wouldn't be very hard to implement, either. Maybe a good
> > starter project or #leftoverbits for somebody.
>
> Maybe. I think that it's made a little more complicated by the above,
> but it's certainly doable. Maybe good for GSoC?
I was thinking it was just the --no-edit fix. :) Even with the "--amend"
thing, though, it's probably a little light for a 3-month-long GSoC
project. :)
-Peff
Re: Feature request: Add --no-edit to git tag command
On Thu, Apr 04, 2019 at 06:13:16PM +0900, Junio C Hamano wrote: > >> Similar to git commit, it would be nice to have a --no-edit option for > >> git tag. Use case is when I force-recreate a tag: > >> > >> $ git tag -af 1.0 123abc > >> > >> An editor will be prompted with the previous annotated tag message. I > >> would like to add --no-edit to instruct it to use any previously > >> provided message and without prompting the editor: > >> > >> $ git tag --no-edit -af 1.0 123abc > > > > Yeah, that sounds like a good idea. > > I am not so sure this is a good idea, especially if the plan is to > do this alone without necessary associated change to make things > consistent. I think I may have misunderstood the request. I thought it was "we already do this re-use the tag message thing, but --no-edit is broken". And the proposal was to fix --no-edit. Which is definitely broken, and it seems like a no-brainer to fix. But looking at the code, yeah, I see that we do not do that. The proposal is to implement both halves. And... > The part that bothers me most is use of "-f". The mentalitly behind > "-f" is "I am creating a new and tag that is totally unrelated to > any existing tag, but since the command refuses to reuse the ref to > point at my new tag, I am giving an '-f' to force (1) unpointing the > existing unrelated tag and (2) pointing the enwly created tag with > that tagname". > > The proposed change still uses "-f" but wants to somehow take the > tag message from the unrelated tag that happens to sit at the same > place as the new tag wants to go. That breaks the mental model a > big way. > > If this were a new option that is spelled "--amend", I won't > be complaining, though. Yes, I agree with all of this. Calling it "--amend" is much better (and/or adding the equivalent of "commit -c" to pick up the message from an existing tag, though maybe "--amend existing-name new-target" would be enough to repoint a tag with the same name). -Peff
Re: Feature request: Add --no-edit to git tag command
Jeff King writes: > On Wed, Apr 03, 2019 at 09:38:02AM -0500, Robert Dailey wrote: > >> Similar to git commit, it would be nice to have a --no-edit option for >> git tag. Use case is when I force-recreate a tag: >> >> $ git tag -af 1.0 123abc >> >> An editor will be prompted with the previous annotated tag message. I >> would like to add --no-edit to instruct it to use any previously >> provided message and without prompting the editor: >> >> $ git tag --no-edit -af 1.0 123abc > > Yeah, that sounds like a good idea. I am not so sure this is a good idea, especially if the plan is to do this alone without necessary associated change to make things consistent. The part that bothers me most is use of "-f". The mentalitly behind "-f" is "I am creating a new and tag that is totally unrelated to any existing tag, but since the command refuses to reuse the ref to point at my new tag, I am giving an '-f' to force (1) unpointing the existing unrelated tag and (2) pointing the enwly created tag with that tagname". The proposed change still uses "-f" but wants to somehow take the tag message from the unrelated tag that happens to sit at the same place as the new tag wants to go. That breaks the mental model a big way. If this were a new option that is spelled "--amend", I won't be complaining, though.
Re: Feature request: Add --no-edit to git tag command
Hi Peff, On Wed, Apr 03, 2019 at 09:57:44PM -0400, Jeff King wrote: > On Wed, Apr 03, 2019 at 09:38:02AM -0500, Robert Dailey wrote: > > > Similar to git commit, it would be nice to have a --no-edit option for > > git tag. Use case is when I force-recreate a tag: > > > > $ git tag -af 1.0 123abc > > > > An editor will be prompted with the previous annotated tag message. I > > would like to add --no-edit to instruct it to use any previously > > provided message and without prompting the editor: > > > > $ git tag --no-edit -af 1.0 123abc > > Yeah, that sounds like a good idea. Agreed. I think that the implement is a little different than "add a --no-edit" flag, though. 'git tag' already has a OPT_BOOL for '--edit', which means that '--no-edit' exists, too. But, when we look and see how the edit option is passed around, we find that the check whether or not to launch the editor (again, in builtin/tag.c within 'create_tag()') is: if (!opt->message_given || opt->use_editor) So, it's not that we didn't take '--no-edit', it's that we didn't get a _message_, so we'll open the editor to get one (even if '--no-edit' was given). This makes me think that we should do two things: 1. Make !opt->message_give && !opt->use_editor an invalid invocation. If I (1) didn't give a message but I did (2) give '--no-edit', I'd expect a complaint, not an editor window. 2. Then, do what Robert suggests, which is to "make opt->message_given true", by re-using the previous tag's message. > I think it wouldn't be very hard to implement, either. Maybe a good > starter project or #leftoverbits for somebody. Maybe. I think that it's made a little more complicated by the above, but it's certainly doable. Maybe good for GSoC? > -Peff Thanks, Taylor
Re: Feature request: Add --no-edit to git tag command
On Wed, Apr 03, 2019 at 09:38:02AM -0500, Robert Dailey wrote: > Similar to git commit, it would be nice to have a --no-edit option for > git tag. Use case is when I force-recreate a tag: > > $ git tag -af 1.0 123abc > > An editor will be prompted with the previous annotated tag message. I > would like to add --no-edit to instruct it to use any previously > provided message and without prompting the editor: > > $ git tag --no-edit -af 1.0 123abc Yeah, that sounds like a good idea. I think it wouldn't be very hard to implement, either. Maybe a good starter project or #leftoverbits for somebody. -Peff
Re: Feature Request git clone shallow-include
On Sat, Mar 30, 2019 at 5:02 AM Joe Enzminger wrote: > > Duy - > > Any updates on this feature request? Nope. I've been busy with other stuff. I did have a look at the possibility of reusing code in sha1-name.c and concluded that it's not quite safe. > Joe > > On Thu, Feb 21, 2019 at 7:06 AM Duy Nguyen wrote: > > > > On Thu, Feb 21, 2019 at 1:07 AM Joe Enzminger > > wrote: > > > > > > That is correct. What you suggest is actually what I tried (using > > > sha-1 syntax). For my purposes, excluding the tag's parent's but > > > including the tag is sufficient, but if is fairly straightforward to > > > extend support to the other use cases I'm sure someone would find is > > > useful. > > > > It's not hard to do. I hope I will find some time to do it soon. My > > only concern is whether reuse the current code or write new. The > > former makes it easy to accidentally accept some extended sha-1 syntax > > that should not run on the server side. On the other hand, the latter > > will not be as thoroughly tested because it only runs by shallow code. > > That's my problem though. I think I might be able to find a third > > option somewhere in between. > > > > > > > > Joe > > > > > > > > > On Tue, Feb 19, 2019 at 7:22 PM Duy Nguyen wrote: > > > > > > > > On Wed, Feb 20, 2019 at 7:07 AM Joe Enzminger > > > > wrote: > > > > > > > > > > Currently, git clone supports shallow-exclude=. The client > > > > > will clone up to, but not including, the commit with the tag. > > > > > > > > > > It would be useful to have the ability to include the commit with the > > > > > tag. The suggestion would be to add a "shallow-include" options to > > > > > clone to support this behavior. > > > > > > > > So exclude the tag's parents and everything before, but keep the tag, > > > > correct? > > > > > > > > I think if we support --shallow-exclude=^ then it should work the > > > > way you want (if the tag is a normal merge you may need to add > > > > --shallow-exclude=^2 as well). And you can do even fancier thing > > > > like --shallow-exclude=~3 (i.e. exclude the grand grand parent > > > > of the tag, but keep the tag and grand parents). We will need to > > > > restrict extended SHA-1 syntax to a safe subset of course. > > > > > > > > > I have tried to use shallow-exclude with a follow on git fetch > > > > > --deepen=1, but it always returns "fatal: error in object; unshallow > > > > > " > > > > -- > > > > Duy > > > > > > > > -- > > Duy -- Duy
Re: Feature Request git clone shallow-include
Duy - Any updates on this feature request? Joe On Thu, Feb 21, 2019 at 7:06 AM Duy Nguyen wrote: > > On Thu, Feb 21, 2019 at 1:07 AM Joe Enzminger > wrote: > > > > That is correct. What you suggest is actually what I tried (using > > sha-1 syntax). For my purposes, excluding the tag's parent's but > > including the tag is sufficient, but if is fairly straightforward to > > extend support to the other use cases I'm sure someone would find is > > useful. > > It's not hard to do. I hope I will find some time to do it soon. My > only concern is whether reuse the current code or write new. The > former makes it easy to accidentally accept some extended sha-1 syntax > that should not run on the server side. On the other hand, the latter > will not be as thoroughly tested because it only runs by shallow code. > That's my problem though. I think I might be able to find a third > option somewhere in between. > > > > > Joe > > > > > > On Tue, Feb 19, 2019 at 7:22 PM Duy Nguyen wrote: > > > > > > On Wed, Feb 20, 2019 at 7:07 AM Joe Enzminger > > > wrote: > > > > > > > > Currently, git clone supports shallow-exclude=. The client > > > > will clone up to, but not including, the commit with the tag. > > > > > > > > It would be useful to have the ability to include the commit with the > > > > tag. The suggestion would be to add a "shallow-include" options to > > > > clone to support this behavior. > > > > > > So exclude the tag's parents and everything before, but keep the tag, > > > correct? > > > > > > I think if we support --shallow-exclude=^ then it should work the > > > way you want (if the tag is a normal merge you may need to add > > > --shallow-exclude=^2 as well). And you can do even fancier thing > > > like --shallow-exclude=~3 (i.e. exclude the grand grand parent > > > of the tag, but keep the tag and grand parents). We will need to > > > restrict extended SHA-1 syntax to a safe subset of course. > > > > > > > I have tried to use shallow-exclude with a follow on git fetch > > > > --deepen=1, but it always returns "fatal: error in object; unshallow > > > > " > > > -- > > > Duy > > > > -- > Duy
Re: Feature Request git clone shallow-include
On Thu, Feb 21, 2019 at 1:07 AM Joe Enzminger wrote: > > That is correct. What you suggest is actually what I tried (using > sha-1 syntax). For my purposes, excluding the tag's parent's but > including the tag is sufficient, but if is fairly straightforward to > extend support to the other use cases I'm sure someone would find is > useful. It's not hard to do. I hope I will find some time to do it soon. My only concern is whether reuse the current code or write new. The former makes it easy to accidentally accept some extended sha-1 syntax that should not run on the server side. On the other hand, the latter will not be as thoroughly tested because it only runs by shallow code. That's my problem though. I think I might be able to find a third option somewhere in between. > > Joe > > > On Tue, Feb 19, 2019 at 7:22 PM Duy Nguyen wrote: > > > > On Wed, Feb 20, 2019 at 7:07 AM Joe Enzminger > > wrote: > > > > > > Currently, git clone supports shallow-exclude=. The client > > > will clone up to, but not including, the commit with the tag. > > > > > > It would be useful to have the ability to include the commit with the > > > tag. The suggestion would be to add a "shallow-include" options to > > > clone to support this behavior. > > > > So exclude the tag's parents and everything before, but keep the tag, > > correct? > > > > I think if we support --shallow-exclude=^ then it should work the > > way you want (if the tag is a normal merge you may need to add > > --shallow-exclude=^2 as well). And you can do even fancier thing > > like --shallow-exclude=~3 (i.e. exclude the grand grand parent > > of the tag, but keep the tag and grand parents). We will need to > > restrict extended SHA-1 syntax to a safe subset of course. > > > > > I have tried to use shallow-exclude with a follow on git fetch > > > --deepen=1, but it always returns "fatal: error in object; unshallow > > > " > > -- > > Duy -- Duy
Re: Feature Request git clone shallow-include
That is correct. What you suggest is actually what I tried (using sha-1 syntax). For my purposes, excluding the tag's parent's but including the tag is sufficient, but if is fairly straightforward to extend support to the other use cases I'm sure someone would find is useful. Joe On Tue, Feb 19, 2019 at 7:22 PM Duy Nguyen wrote: > > On Wed, Feb 20, 2019 at 7:07 AM Joe Enzminger > wrote: > > > > Currently, git clone supports shallow-exclude=. The client > > will clone up to, but not including, the commit with the tag. > > > > It would be useful to have the ability to include the commit with the > > tag. The suggestion would be to add a "shallow-include" options to > > clone to support this behavior. > > So exclude the tag's parents and everything before, but keep the tag, correct? > > I think if we support --shallow-exclude=^ then it should work the > way you want (if the tag is a normal merge you may need to add > --shallow-exclude=^2 as well). And you can do even fancier thing > like --shallow-exclude=~3 (i.e. exclude the grand grand parent > of the tag, but keep the tag and grand parents). We will need to > restrict extended SHA-1 syntax to a safe subset of course. > > > I have tried to use shallow-exclude with a follow on git fetch > > --deepen=1, but it always returns "fatal: error in object; unshallow > > " > -- > Duy
Re: Feature Request git clone shallow-include
On Wed, Feb 20, 2019 at 7:07 AM Joe Enzminger wrote: > > Currently, git clone supports shallow-exclude=. The client > will clone up to, but not including, the commit with the tag. > > It would be useful to have the ability to include the commit with the > tag. The suggestion would be to add a "shallow-include" options to > clone to support this behavior. So exclude the tag's parents and everything before, but keep the tag, correct? I think if we support --shallow-exclude=^ then it should work the way you want (if the tag is a normal merge you may need to add --shallow-exclude=^2 as well). And you can do even fancier thing like --shallow-exclude=~3 (i.e. exclude the grand grand parent of the tag, but keep the tag and grand parents). We will need to restrict extended SHA-1 syntax to a safe subset of course. > I have tried to use shallow-exclude with a follow on git fetch > --deepen=1, but it always returns "fatal: error in object; unshallow > " -- Duy
Re: Feature request on git log --oneline -- ...
Ævar Arnfjörð Bjarmason writes: > What do you think such an option should do when it finds negative path > specs, e.g. this on git.git: > > git log --oneline --stat -- ':!/Makefile' '*Makefile*' > > Should it only render positive matches, or distinguish between > matched/blacklisted/not-matched, your example (with no negative > patspecs) just shows matched/not-matched. Another thing to consider is what this would do to the merge simplification. If I understand it correctly, this is sort-of like a reverse of the "--full-diff" option, where the pathspec *is* used to limit and simplify the history, but for the purpose of displaying "log -p" output, the pathspec is widened to show the entire change. This instead makes the traversal ignore the pathspec and uses it only to limit the "log -p" output. I do not think I would be fundamentally opposed to a feature like this.
Re: Feature request on git log --oneline -- ...
On Wed, Feb 13, 2019 at 4:27 PM Petri Gynther wrote: > > git developers: > > Small feature request on: > git log --oneline -- ... > > Could we add an option to: > 1) display all commits in unconditionally > 2) use a special marker (e.g. star) for commits that touch ... > and list the files from ... that this commit modified > > Sample output: > git log --oneline (--annotated?) HEAD~5..HEAD -- Makefile > kernel/printk/printk.c > > ccc1 uninteresting commit 1 > * ccc2 fix Makefile > Makefile > ccc3 uninteresting commit 2 > * ccc4 fix Makefile and printk() > Makefile > kernel/printk/printk.c > ccc5 uninteresting commit 3 > > In other words: > - commits that don't touch ... are still listed (without special > markers) > - commits that touch ... are listed with * prefix, and the files > from ... that the commit modified are listed below the commit > > This is very useful for kernel LTS merges, when we want to know which > LTS patches in the merge chain actually touched the files that matter > for a specific build target. > > Is this an easy add-on to git log? Adding the "*" is not that hard, I think. The hard part is UI. Soon somebody may want to "list commits touching sub/ then add "*" on ones that touch sub/dir/". Meanwhile I think you can still achieve that with a bit of scripting and processing "git log --raw --oneline " output. -- Duy
Re: Feature request on git log --oneline -- ...
On Wed, Feb 13 2019, Petri Gynther wrote: > git developers: > > Small feature request on: > git log --oneline -- ... > > Could we add an option to: > 1) display all commits in unconditionally > 2) use a special marker (e.g. star) for commits that touch ... > and list the files from ... that this commit modified > > Sample output: > git log --oneline (--annotated?) HEAD~5..HEAD -- Makefile > kernel/printk/printk.c > > ccc1 uninteresting commit 1 > * ccc2 fix Makefile > Makefile > ccc3 uninteresting commit 2 > * ccc4 fix Makefile and printk() > Makefile > kernel/printk/printk.c > ccc5 uninteresting commit 3 > > In other words: > - commits that don't touch ... are still listed (without special > markers) > - commits that touch ... are listed with * prefix, and the files > from ... that the commit modified are listed below the commit > > This is very useful for kernel LTS merges, when we want to know which > LTS patches in the merge chain actually touched the files that matter > for a specific build target. What do you think such an option should do when it finds negative path specs, e.g. this on git.git: git log --oneline --stat -- ':!/Makefile' '*Makefile*' Should it only render positive matches, or distinguish between matched/blacklisted/not-matched, your example (with no negative patspecs) just shows matched/not-matched. > Is this an easy add-on to git log? It's been a while since I looked at this code, but (depending on the answer to the above) I don't think it would be that hard. We already pass up what we matched for the --stat machinery. E.g. try on git.git: git log --oneline -1 --stat 32ceace39f -- git log --oneline -1 --stat 32ceace39f -- '*fetch.c' The former shows a few modified *.c files in the --stat, the latter just builtin/fetch.c since it matched.
Re: Feature request: --preserve-merges to add "exec git merge ..." instead of "pick ..."
Andreas Hennings writes: > I tried this option after upgrading my git. > Unfortunately, no matter which variation I use, it still attempts to > rebase most or all of the feature branches before merging them. > Possibly depending on their ancestry. Yes, I know that. But what I am hoping is that it won't actually touch the commits on the side branches UNLESS you tell in the insn sequence to modify them with "edit", "reword", etc. and instead fast-forward them. Of course, it will allow you to muck with these commits on the side branches, which is a potential source of mistakes.
Re: Feature request: --preserve-merges to add "exec git merge ..." instead of "pick ..."
I tried this option after upgrading my git. Unfortunately, no matter which variation I use, it still attempts to rebase most or all of the feature branches before merging them. Possibly depending on their ancestry. On Mon, 7 Jan 2019 at 22:12, Andreas Hennings wrote: > > It sounds good! > I was using git version 2.7.4 all the time. I should have checked > before posting here :) > Now trying 2.20.1 > > From "git help rebase": > >By default, or when no-rebase-cousins was specified, > commits which do not have as direct ancestor will keep > their >original branch point, i.e. commits that would be excluded > by gitlink:git-log[1]'s --ancestry-path option will keep their >original ancestry by default. If the rebase-cousins mode is > turned on, such commits are instead rebased onto (or >, if specified). > > I am not sure if this criterion (which ancestors it has) will always > produce the behavior I am looking for. > I will have to experiment a bit. > > Thanks for now, I will post again with new thoughts once I have done > some experiments. > > On Mon, 7 Jan 2019 at 17:42, Junio C Hamano wrote: > > > > Andreas Hennings writes: > > > > > This means we need a rebase operation where: > > > - The commits of the acceptance branch itself are being replaced. > > > - The commits of the feature branches remain as they are. > > > > > > A "git rebase --preserve-merges" almost does this, but not really. > > > > This wished-for feature sounds to me more like the "first-parent" > > mode that has been discussed a few times in the past but never > > materialized. > > > > The preserve-merges mode is getting abandoned by the original author > > as unsalvageable. Have you tried the rebase-merges mode? That may > > let you choose replaying only the merge commits on the acceptance > > branch without touching the tips of the feature branches getting > > merged.
Re: Feature request: --preserve-merges to add "exec git merge ..." instead of "pick ..."
It sounds good! I was using git version 2.7.4 all the time. I should have checked before posting here :) Now trying 2.20.1 >From "git help rebase": By default, or when no-rebase-cousins was specified, commits which do not have as direct ancestor will keep their original branch point, i.e. commits that would be excluded by gitlink:git-log[1]'s --ancestry-path option will keep their original ancestry by default. If the rebase-cousins mode is turned on, such commits are instead rebased onto (or , if specified). I am not sure if this criterion (which ancestors it has) will always produce the behavior I am looking for. I will have to experiment a bit. Thanks for now, I will post again with new thoughts once I have done some experiments. On Mon, 7 Jan 2019 at 17:42, Junio C Hamano wrote: > > Andreas Hennings writes: > > > This means we need a rebase operation where: > > - The commits of the acceptance branch itself are being replaced. > > - The commits of the feature branches remain as they are. > > > > A "git rebase --preserve-merges" almost does this, but not really. > > This wished-for feature sounds to me more like the "first-parent" > mode that has been discussed a few times in the past but never > materialized. > > The preserve-merges mode is getting abandoned by the original author > as unsalvageable. Have you tried the rebase-merges mode? That may > let you choose replaying only the merge commits on the acceptance > branch without touching the tips of the feature branches getting > merged.
Re: Feature request: --preserve-merges to add "exec git merge ..." instead of "pick ..."
Andreas Hennings writes: > This means we need a rebase operation where: > - The commits of the acceptance branch itself are being replaced. > - The commits of the feature branches remain as they are. > > A "git rebase --preserve-merges" almost does this, but not really. This wished-for feature sounds to me more like the "first-parent" mode that has been discussed a few times in the past but never materialized. The preserve-merges mode is getting abandoned by the original author as unsalvageable. Have you tried the rebase-merges mode? That may let you choose replaying only the merge commits on the acceptance branch without touching the tips of the feature branches getting merged.
Re: Feature request: Provide porcelain to manage symbolic references as branch aliases
Updating the proof-of-concept script for this feature request. (See attachment.) I'm quoting the entire original message for reference, just because it's been a while since I proposed this. -Phil On 30/04/14 00:51, Phil Sainty wrote: > Most of the plumbing for having branch name aliases already exists > in the form of symbolic references, and people do use them for this > purpose; but I get the impression that it's not really supported > officially, and I'm not aware of any porcelain features to > facilitate this use-case. > > I'd like to propose that such porcelain be added. I feel that a new > argument to 'git branch' would make the most sense: > > git branch --alias [] > > For reference/testing, I'm attaching a wrapper script I wrote to > implement the same functionality (as a separate command). I did this > primarily to provide the error-checking I felt was needed to make it > practical to use branch aliases -- git symbolic-ref will happily > trash your branch references if you make a mistake, whereas it's > pretty difficult to mess anything up with my git-branch-alias script. > > Thus far it's worked nicely for me. Examples: > > $ git branch-alias # create alias > $ git branch-alias # create alias for current branch > $ git branch # view branches and branch aliases > $ git log > $ git checkout > $ git push origin # pushes the branch, not the alias/reference > $ git branch-alias -d # delete an alias safely > > n.b. For my proposed porcelain change, these examples would become: > $ git branch --alias # creates alias > $ git branch --alias # create alias for current branch > $ git branch --delete # works since 1.8.0.1, but see below. > > > Since using this script, the only thing I've spotted that I'd like > to be different is the commit message if I "git merge ". The > commit message indicates that I've merged rather than the > that it points at. I'd prefer that it was dereferenced > when the message was generated, so that the real branch name was > printed instead. > > > That niggle aside, significant things I noted along the way were: > > 1. Git 1.8.0.1 fixed the problem whereby git branch -d >used to dereference and therefore delete the branch >it pointed at, rather than the reference. > > 2. HOWEVER if you have checked out at the time you >delete it, you're in trouble -- git allows you to do it, and >you're then left with an invalid HEAD reference. > >(I think this ought to be considered a current bug in git.) > > 3. I resolved that situation (2) by using "git symbolic-ref HEAD" >to find the target ref, and setting HEAD to that target. Nothing >changes for the user, but we can now delete the reference safely. > >HOWEVER, there's a problem with detecting that situation (2) >in the first place: > > 4. Chains of references are de-referenced atomically -- the entire >reference chain is followed to its end; and I could find no >facility to obtain ONLY the "next link of the chain". > >This means we can't use "git symbolic-ref HEAD" to check whether >it points to another reference. In my script I had to resort to >inspecting HEAD manually, which obviously isn't desirable. > >I think a new argument is warranted here, perhaps something like: >"git symbolic-ref --max-deref-count=1" > >I'll justify that on the assumption that (2) needs fixing in git >regardless, either by: > >(i) Not allowing the user to delete the checked-out symref (which >would be consistent with the behaviour if the user attempts to >"git branch -d " (for an actual branch name) when that >is the currently checked-out branch. > >or, >(ii) Using the approach I've taken: silently setting HEAD to the > branch to which the symref points before deleting that symref. > (I couldn't see any reason not to use this approach.) > >But as in both cases we need to detect that HEAD is the symref >being deleted, which means that we need the ability to explicitly >dereference only a single step of a reference chain. > > > -Phil > #!/bin/sh # git branch-alias # Author: Phil S. # Version 1.11 version=1.11 # Creates branch aliases, so that you can refer to a long branch name # by a convenient short alias. This is particularly useful for branch # names beginning with bug-tracker ID numbers (or similar), where the # benefits of tab-completion are greatly reduced. # This is mostly a "do what I mean" wrapper around "git symbolic-ref", # with numerous safety measures included in order to eliminate the # (otherwise considerable) risk of trashing a branch if you get your # arguments wrong. # Installation: # Place this script somewhere in your PATH and name it "git-branch-alias" # and you will be able to invoke it with "git branch-alias" as per the # following examples. # Examples: # git branch-alias # create alias # git branch-alias # create alias for current branch # git branch # view branches and branc
Re: Feature request: be able to pass arguments to difftool command
David Aguilar writes: > While I do see the utility, it would be just as easy to configure a 2nd > and 3rd variant of the same difftool and use those as needed instead. > > "git difftool -t ccdiff2" or "-t ccdiff3" is the simplest, and there's > nothing stopping the user from creating aliases to shorten it further. > ... > We already have two mechanisms for controlling the inner command that's > launched by difftool. IMO we don't need more. OK, fair enough.
Re: Feature request: be able to pass arguments to difftool command
On Wed, Aug 29, 2018 at 09:18:38AM +0200, H.Merijn Brand wrote:
> On Tue, 28 Aug 2018 12:37:40 -0700, Junio C Hamano
> wrote:
>
> > "H.Merijn Brand" writes:
> >
> > > So, my wish would be to have an option, possibly using -- to pass
> > > additional command line arguments to git difftool, so that
> > >
> > > $ git difftool $commit~1..$commit -- -m -v2
> > >
> > > would pass the arguments after -- transparantly to ccdiff (in my case)
> >
> > At the syntax level passing any option after "--" would be a no
> > starter, as I would imagine that "git difftool $revs -- $paths"
> > should still be supported.
> >
> > At the concept level, however, I can see why such a feature would be
> > useful. Perhaps
> >
> > $ git difftool --backend-option=-m --backend-option=-v2 HEAD
> > $ git mergetool --backend-option=--foo
>
> This would mean I can just pass remaining arguments, like this?
>
> --8<--- ~/bin/git-ccdiff
> #!/usr/bin/env perl
> use 5.18.3;
> use warnings;
>
> my $commit;
>
> @ARGV && $ARGV[0] !~ m/^-/ and $commit = shift;
>
> my @git = qw( git difftool );
> defined $commit and push @git, "$commit~1..$commit";
> system @git, @ARGV;
> -->8---
>
> > with appropriate way(s) [*1*] to make it easier to type (and
> > implement) would be an acceptable avenue to pursue, I wonder?
>
> I like it, as long as they are all separate options in the backend and
> not available in one single variable that needs to be split
>
> I can envision a configure variable like
>
> backends.options.separator = U+2063
>
> so the backend can safely split on that itself. But I also see this as
> overly complex en over-engineering
Personally, I think it'd be better to keep the tool simple.
While I do see the utility, it would be just as easy to configure a 2nd
and 3rd variant of the same difftool and use those as needed instead.
"git difftool -t ccdiff2" or "-t ccdiff3" is the simplest, and there's
nothing stopping the user from creating aliases to shorten it further.
We also already have, "git difftool -x / --extcmd"
for specifying a full-on external diff command.
> git -c difftool.ccdiff.opts=-v2 -c difftool.ccdiff.opts=-m difftool
For example, this seems simpler as:
git difftool -x 'ccdiff -v2 -m'
We already have two mechanisms for controlling the inner command that's
launched by difftool. IMO we don't need more.
My primary concerns with --backend-opts are as follows:
1. If we add a mechansim for passing -X/--backend-opts, then we
need to specify a new variable that users will need to be aware
of when creating custom commands. (sorry for stating the obvious)
2. All of the built-in commands would need to change to honor that
variable.
3. The documentation becomes more complex because someone that wants
to configure a bog-standard custom external tool now needs to
be aware of this extra external source of arguments.
#1 and #2 are primarily implementation concerns, but #3 suggests
to me that it's over-complicating things.
Furthermore, #2 is not really that simple.
What would the sciplet look like?
diff_cmd () {
"$merge_tool_path" $EXTRA_ARGS ...
}
That implies that we would need to shell quote stuff when
constructing $EXTRA_ARGS internally if we were to support multiple -X
arguments. That just made it a bit more complex.
IMO we should be working to simpliify, not make things more complex for
rare use cases. There's no reason the user can't just do:
V=2 git difftool
V=3 git difftool
... and let the inner script check for $V (or any other) variable.
While environment variables aren't great, this does seem like the right
place to use them.
Another option -- we already eval the configured command, so if the user
includes a variable ($ARGS) in their custom configuration then they can
specify extra flags today without needing to change the tool. ex:
[difftool "ccdiff"]
cmd = ccdiff $ARGS \"$LOCAL\" \"$REMOTE\"
ARGS='-v2 -m' git difftool HEAD~1..HEAD
Are these alternatives short and simple enough?
--
David
Re: Feature request: hooks directory
Hello Christian, 2018-09-03 6:00 GMT+02:00 Christian Couder : > Hi Wesley, > > On Sun, Sep 2, 2018 at 11:38 PM, Wesley Schwengle wrote: >> Hi all, >> >> I've made some progress with the hook.d implementation. It isn't >> finished, as it is my first C project I'm still somewhat rocky with >> how pointers and such work, but I'm getting somewhere. I haven't >> broken any tests \o/. > > Great! Welcome to the Git community! Thank you! >> You have a nice testsuite btw. Feel free to comment on the code. >> >> I've moved some of the hooks-code found in run-command.c to hooks.c >> >> You can see the progress on gitlab: https://gitlab.com/waterkip/git >> or on github: https://github.com/waterkip/git >> The output of format-patch is down below. > > It would be nicer if you could give links that let us see more > directly the commits you made, for example: > https://gitlab.com/waterkip/git/commits/multi-hooks Yeah.. sorry about that. Let's just say I was excited to send my progress to the list. >> I have some questions regarding the following two functions in run-command.c: >> * run_hook_le >> * run_hook_ve >> >> What do the postfixes le and ve mean? > > It's about the arguments the function accepts, in a similar way to > exec*() functions, see `man execve` and `man execle`. > In short 'l' means list, 'v' means array of pointer to strings and 'e' > means environment. Thanks, I'll have a look at these functions later today. >> format-patch: >> >> From 129d8aff8257b22210beadc155cdbcae99b0fc4b Mon Sep 17 00:00:00 2001 >> From: Wesley Schwengle >> Date: Sun, 2 Sep 2018 02:40:04 +0200 >> Subject: [PATCH] WIP: Add hook.d support in git > > This is not the best way to embed a patch in an email. There is > Documentation/SubmittingPatches in the code base, that should explain > better ways to send patches to the mailing list. I saw that as well, after I've submitted the e-mail and was looking at the travis documentation. I'll promise I'll do better for my next patch submission. Sorry about this.. >> Add a generic mechanism to find and execute one or multiple hooks found >> in $GIT_DIR/hooks/ and/or $GIT_DIR/hooks/.d/* >> >> [snip] >> >> * All the scripts are executed and fail on the first error > > Maybe the above documentation should be fully embedded as comments in > "hooks.h" (or perhaps added to a new file in > "Documentation/technical/", though it looks like we prefer to embed > doc in header files these days). I've added this to "hooks.h". If you guys want some documentation in "Documentation/technical", I'm ok with adding a new file there as well. >> diff --git a/hooks.h b/hooks.h >> new file mode 100644 >> index 0..278d63344 >> --- /dev/null >> +++ b/hooks.h >> @@ -0,0 +1,35 @@ >> +#ifndef HOOKS_H >> +#define HOOKS_H >> + >> +#ifndef NO_PTHREADS >> +#include >> +#endif >> +/* >> + * Returns all the hooks found in either >> + * $GIT_DIR/hooks/$hook and/or $GIT_DIR/hooks/$hook.d/ >> + * >> + * Note that this points to static storage that will be >> + * overwritten by further calls to find_hooks and run_hook_*. >> + */ >> +//extern const struct string_list *find_hooks(const char *name); > > The above comment is using "//" which we forbid and should probably be > removed anyway. Thanks, I have a "//" comment elsewhere, I'll change/remove it. >> +extern const char *find_hooks(const char *name); >> + >> +/* Unsure what this does/is/etc */ >> +//LAST_ARG_MUST_BE_NULL > > This is to make it easier for tools like compilers to check that a > function is used correctly. You should not remove such macros. Check. >> +/* >> + * Run all the runnable hooks found in >> + * $GIT_DIR/hooks/$hook and/or $GIT_DIR/hooks/$hook.d/ >> + * >> + */ >> +//extern int run_hooks_le(const char *const *env, const char *name, ...); >> +//extern int run_hooks_ve(const char *const *env, const char *name, >> va_list args); > > Strange that these functions are commented out. These two functions are still in "run-command.h" and I want to move them to "hooks.h" and friends. But I first wanted to make sure "find_hooks" worked as intended. This is still on my TODO for this week. >> +#endif >> + >> +/* Workings of hooks >> + * >> + * array_of_hooks = find_hooks(name); >> + * number_of_hooks_ran = run_hooks(array_of_hooks); >> + * >> + */ > > This kind of documentation should probably be at the beginning of the > file, see strbuf.h for example. Since I added the better part of the commit message in "hooks.h" I removed this bit. An additional question: In my patch I've added "hooks.multiHook", which I think I should rename to "hooks.hooksd". It is wanted to change "core.hooksPath" to the "hooks" namespace? Or should I rename my new config item to "core.hooksd"? Cheers, Wesley -- Wesley Schwengle, Developer Mintlab B.V., https://www.zaaksysteem.nl E: wes...@mintlab.nl T: +31 20 737 00 05
Re: Feature request: hooks directory
Hi Wesley,
On Sun, Sep 2, 2018 at 11:38 PM, Wesley Schwengle wrote:
> Hi all,
>
> I've made some progress with the hook.d implementation. It isn't
> finished, as it is my first C project I'm still somewhat rocky with
> how pointers and such work, but I'm getting somewhere. I haven't
> broken any tests \o/.
Great! Welcome to the Git community!
> You have a nice testsuite btw. Feel free to comment on the code.
>
> I've moved some of the hooks-code found in run-command.c to hooks.c
>
> You can see the progress on gitlab: https://gitlab.com/waterkip/git
> or on github: https://github.com/waterkip/git
> The output of format-patch is down below.
It would be nicer if you could give links that let us see more
directly the commits you made, for example:
https://gitlab.com/waterkip/git/commits/multi-hooks
> I have some questions regarding the following two functions in run-command.c:
> * run_hook_le
> * run_hook_ve
>
> What do the postfixes le and ve mean?
It's about the arguments the function accepts, in a similar way to
exec*() functions, see `man execve` and `man execle`.
In short 'l' means list, 'v' means array of pointer to strings and 'e'
means environment.
> format-patch:
>
> From 129d8aff8257b22210beadc155cdbcae99b0fc4b Mon Sep 17 00:00:00 2001
> From: Wesley Schwengle
> Date: Sun, 2 Sep 2018 02:40:04 +0200
> Subject: [PATCH] WIP: Add hook.d support in git
This is not the best way to embed a patch in an email. There is
Documentation/SubmittingPatches in the code base, that should explain
better ways to send patches to the mailing list.
> Add a generic mechanism to find and execute one or multiple hooks found
> in $GIT_DIR/hooks/ and/or $GIT_DIR/hooks/.d/*
>
> The API is as follows:
>
> #include "hooks.h"
>
> array hooks = find_hooks('pre-receive');
> int hooks_ran = run_hooks(hooks);
>
> The implemented behaviour is:
>
> * If we find a hooks/.d directory and the hooks.multiHook flag isn't
> set we make use of that directory.
>
> * If we find a hooks/.d and we also have hooks/ and the
> hooks.multiHook isn't set or set to false we don't use the hook.d
> directory. If the hook isn't set we issue a warning to the user
> telling him/her that we support multiple hooks via the .d directory
> structure
>
> * If the hooks.multiHook is set to true we use the hooks/ and all
> the entries found in hooks/.d
>
> * All the scripts are executed and fail on the first error
Maybe the above documentation should be fully embedded as comments in
"hooks.h" (or perhaps added to a new file in
"Documentation/technical/", though it looks like we prefer to embed
doc in header files these days).
> diff --git a/hooks.h b/hooks.h
> new file mode 100644
> index 0..278d63344
> --- /dev/null
> +++ b/hooks.h
> @@ -0,0 +1,35 @@
> +#ifndef HOOKS_H
> +#define HOOKS_H
> +
> +#ifndef NO_PTHREADS
> +#include
> +#endif
> +/*
> + * Returns all the hooks found in either
> + * $GIT_DIR/hooks/$hook and/or $GIT_DIR/hooks/$hook.d/
> + *
> + * Note that this points to static storage that will be
> + * overwritten by further calls to find_hooks and run_hook_*.
> + */
> +//extern const struct string_list *find_hooks(const char *name);
The above comment is using "//" which we forbid and should probably be
removed anyway.
> +extern const char *find_hooks(const char *name);
> +
> +/* Unsure what this does/is/etc */
> +//LAST_ARG_MUST_BE_NULL
This is to make it easier for tools like compilers to check that a
function is used correctly. You should not remove such macros.
> +/*
> + * Run all the runnable hooks found in
> + * $GIT_DIR/hooks/$hook and/or $GIT_DIR/hooks/$hook.d/
> + *
> + */
> +//extern int run_hooks_le(const char *const *env, const char *name, ...);
> +//extern int run_hooks_ve(const char *const *env, const char *name,
> va_list args);
Strange that these functions are commented out.
> +#endif
> +
> +/* Workings of hooks
> + *
> + * array_of_hooks = find_hooks(name);
> + * number_of_hooks_ran = run_hooks(array_of_hooks);
> + *
> + */
This kind of documentation should probably be at the beginning of the
file, see strbuf.h for example.
Thanks,
Christian.
Re: Feature request: hooks directory
Hi all,
I've made some progress with the hook.d implementation. It isn't
finished, as it is my first C project I'm still somewhat rocky with
how pointers and such work, but I'm getting somewhere. I haven't
broken any tests \o/.
You have a nice testsuite btw. Feel free to comment on the code.
I've moved some of the hooks-code found in run-command.c to hooks.c
You can see the progress on gitlab: https://gitlab.com/waterkip/git
or on github: https://github.com/waterkip/git
The output of format-patch is down below.
I have some questions regarding the following two functions in run-command.c:
* run_hook_le
* run_hook_ve
What do the postfixes le and ve mean?
Cheers,
Wesley
format-patch:
>From 129d8aff8257b22210beadc155cdbcae99b0fc4b Mon Sep 17 00:00:00 2001
From: Wesley Schwengle
Date: Sun, 2 Sep 2018 02:40:04 +0200
Subject: [PATCH] WIP: Add hook.d support in git
Add a generic mechanism to find and execute one or multiple hooks found
in $GIT_DIR/hooks/ and/or $GIT_DIR/hooks/.d/*
The API is as follows:
#include "hooks.h"
array hooks = find_hooks('pre-receive');
int hooks_ran = run_hooks(hooks);
The implemented behaviour is:
* If we find a hooks/.d directory and the hooks.multiHook flag isn't
set we make use of that directory.
* If we find a hooks/.d and we also have hooks/ and the
hooks.multiHook isn't set or set to false we don't use the hook.d
directory. If the hook isn't set we issue a warning to the user
telling him/her that we support multiple hooks via the .d directory
structure
* If the hooks.multiHook is set to true we use the hooks/ and all
the entries found in hooks/.d
* All the scripts are executed and fail on the first error
---
Makefile | 1 +
TODO-hooks.md | 38
builtin/am.c | 4 +-
builtin/commit.c | 4 +-
builtin/receive-pack.c | 10 +--
builtin/worktree.c | 3 +-
cache.h| 1 +
config.c | 5 ++
environment.c | 1 +
hooks.c| 134 +
hooks.h| 35 +++
run-command.c | 36 +--
run-command.h | 6 --
sequencer.c| 7 ++-
transport.c| 3 +-
15 files changed, 237 insertions(+), 51 deletions(-)
create mode 100644 TODO-hooks.md
create mode 100644 hooks.c
create mode 100644 hooks.h
diff --git a/Makefile b/Makefile
index 5a969f583..f5eddf1d7 100644
--- a/Makefile
+++ b/Makefile
@@ -810,6 +810,7 @@ LIB_H = $(shell $(FIND) . \
-name Documentation -prune -o \
-name '*.h' -print)
+LIB_OBJS += hooks.o
LIB_OBJS += abspath.o
LIB_OBJS += advice.o
LIB_OBJS += alias.o
diff --git a/TODO-hooks.md b/TODO-hooks.md
new file mode 100644
index 0..13b15bffb
--- /dev/null
+++ b/TODO-hooks.md
@@ -0,0 +1,38 @@
+# All hooks
+# See Documentation/githooks.txt for more information about each and every hook
+# that git knows about
+commit-msg
+fsmoninor-watchman
+p4-pre-submit
+post-applypatch
+post-checkout
+post-commit
+post-merge
+post-receive
+post-rewrite
+post-update
+pre-applypatch
+pre-auto-gc
+pre-commit
+pre-push
+pre-rebase
+pre-receive
+prepare-commit-msg
+push-to-checkout
+sendemail-validate
+update
+
+# builtin/receive-pack.c
+feed_recieve_hook
+find_hook
+find_receive_hook
+push_to_checkout_hook
+receive_hook_feed_state
+run_and_feed_hook
+run_hook_le
+run_receive_hook
+run_update_hook
+
+
+# run-command.c
+find_hook
diff --git a/builtin/am.c b/builtin/am.c
index 9f7ecf6ec..d1276dd47 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -34,6 +34,8 @@
#include "packfile.h"
#include "repository.h"
+#include "hooks.h"
+
/**
* Returns 1 if the file is empty or does not exist, 0 otherwise.
*/
@@ -509,7 +511,7 @@ static int run_applypatch_msg_hook(struct am_state *state)
static int run_post_rewrite_hook(const struct am_state *state)
{
struct child_process cp = CHILD_PROCESS_INIT;
- const char *hook = find_hook("post-rewrite");
+ const char *hook = find_hooks("post-rewrite");
int ret;
if (!hook)
diff --git a/builtin/commit.c b/builtin/commit.c
index 0d9828e29..389224d66 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -34,6 +34,8 @@
#include "mailmap.h"
#include "help.h"
+#include "hooks.h"
+
static const char * const builtin_commit_usage[] = {
N_("git commit [] [--] ..."),
NULL
@@ -932,7 +934,7 @@ static int prepare_to_commit(const char
*index_file, const char *prefix,
return 0;
}
- if (!no_verify && find_hook("pre-commit")) {
+ if (!no_verify && find_hooks("pre-commit")) {
/*
* Re-read the index as pre-commit hook could have updated it,
* and write it out as a tree. We must do this before we invoke
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index c17ce94e1..dd10ef4af 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -28,6 +28,8 @@
#include "object-store.h"
#include "protocol.h"
+#include "hooks.h"
+
static const char * const receive_pack_usage[] = {
N
Re: Feature request: hooks directory
On Fri, Aug 31 2018, Wesley Schwengle wrote: > Hop, > > 2018-08-30 16:45 GMT+02:00 Ævar Arnfjörð Bjarmason : > >>> Solution: >>> We discussed this at work and we thought about making a .d directory >>> for the hooks, eg. $GIT_DIR/hooks/post-commit.d, where a user can put >>> the post-commit hooks in. This allows us to provide post commit hooks >>> and allows the user to add additional hooks him/herself. We could >>> implement this in our own code base. But we were wondering if this >>> approach could be shared with the git community and if this behavior >>> is wanted in git itself. >> >> There is interest in this. This E-Mail of mine gives a good summary of >> prior discussions about this: >> https://public-inbox.org/git/877eqqnq22@evledraar.gmail.com/ >> >> I.e. it's something I've personally been interested in doing in the >> past, there's various bolt-on solutions to do it (basically local hook >> runners) used by various projects. > > Thank you for the input. Do you by any chance still have that branch? > Or would you advise me to start fresh, if so, do you have any pointers > on where to look as I'm brand new to the git source code? No, sorry. Start by grepping the hook names found in the githooks manpage in the C code. One of the things that's hard, well not hard, just tedious about this, is that most of them are implementing their own ad-hoc way of doing stuff. E.g. the *-receive hooks are in receive-pack.c in run_receive_hook(). There is run_hook_le() and friends, but it's not used by everything. So e.g. for the pre-receive hook in order to run 2 of them instead of 1 you need to untangle the state where we're feeding the hook with the input (and potentially buffer it, not stream it), instead of doing it as a one-off as we're doing now. Then some hooks get nothing on stdin, some get stuff on stdin, some produce output on stdout/stderr etc. As a first approximation, just add a e.g. support for a pre-receive.2 hook, that gets run after pre-receive, to see what needs to be done to run it twice. > From the thread I've extracted three stories: > > 1) As a developer I want to have 'hooks.multiHooks' to enable > multi-hook support in git > Input is welcome for another name. Yeah maybe we should have a setting, but FWIW I think we should just stat() whether the hooks/$hook_name.d directory exist, and then use it, although maybe we'll need stuff like hooks.multiHooks to give the likes of GitLab (which already do that themselves) an upgrade path... You can see their implementation here: https://gitlab.com/gitlab-org/gitlab-shell/blob/master/lib/gitlab_custom_hook.rb > 2) As a developer I want natural sort order executing for my githooks > so I can predict executions > See > https://public-inbox.org/git/CACBZZX6AYBYeb5S4nEBhYbx1r=icJ81JGYBx5=h4wacphhj...@mail.gmail.com/ > for more information Yeah, any sane implementation of this will execute the hooks in hooks/$hook_name.d in glob() order. > 3) As a developer I want to run $GIT_DIR/hooks/ before > $GIT_DIR/hooks/.d/* > Reference: > https://public-inbox.org/git/cacbzzx6j6q2dun_z-pnent1u714dvnpfbrl_pieqylmczlu...@mail.gmail.com/ For e.g. GitLab the hook/pre-receive is a runner that'll run all hook/pre-receive.d/*, so this probably makes sense to hide behind a config setting. I think it's sensible as a default to move to to just try to move away from hooks/ and use hook/.d/* instead. > The following story would be.. nice to have I think. I'm not sure I > would want to implement this from the get go as I don't have a use > case for it. > 4) As a developer I want a way to have a hook report an error and let > another hook decide if we want to pass or not. > Reference: > https://public-inbox.org/git/xmqq60v4don1@gitster.mtv.corp.google.com/ I think a default that makes more sense is a while ! ret = glob() loop, i.e. a failure will do early exit. But yeah. Junio seemed to want this to be configurable. > 2018-08-31 5:16 GMT+02:00 Jonathan Nieder : >> A few unrelated thoughts, to expand on this. >> >> Separately from that, in [1] I mentioned that I want to revamp how >> hooks work somewhat, to avoid the attack described there (or the more >> common attack also described there that involves a zip file). Such a >> revamp would be likely to also handle this multiple-hook use case. >> >> [1] >> https://public-inbox.org/git/20171002234517.gv19...@aiede.mtv.corp.google.com/ > > The zip file attack vector doesn't change with adding a hook.d > directory structure? If I have one file or multiple files, the attack > stays the same? > I think I'm asking if this would be a show stopper for the feature. Yeah I don't see how what Jonathan's talking about there has any relevance to whether we run 1 or 100 hooks.
Re: Feature request: hooks directory
Hop, 2018-08-30 16:45 GMT+02:00 Ævar Arnfjörð Bjarmason : >> Solution: >> We discussed this at work and we thought about making a .d directory >> for the hooks, eg. $GIT_DIR/hooks/post-commit.d, where a user can put >> the post-commit hooks in. This allows us to provide post commit hooks >> and allows the user to add additional hooks him/herself. We could >> implement this in our own code base. But we were wondering if this >> approach could be shared with the git community and if this behavior >> is wanted in git itself. > > There is interest in this. This E-Mail of mine gives a good summary of > prior discussions about this: > https://public-inbox.org/git/877eqqnq22@evledraar.gmail.com/ > > I.e. it's something I've personally been interested in doing in the > past, there's various bolt-on solutions to do it (basically local hook > runners) used by various projects. Thank you for the input. Do you by any chance still have that branch? Or would you advise me to start fresh, if so, do you have any pointers on where to look as I'm brand new to the git source code? >From the thread I've extracted three stories: 1) As a developer I want to have 'hooks.multiHooks' to enable multi-hook support in git Input is welcome for another name. 2) As a developer I want natural sort order executing for my githooks so I can predict executions See https://public-inbox.org/git/CACBZZX6AYBYeb5S4nEBhYbx1r=icJ81JGYBx5=h4wacphhj...@mail.gmail.com/ for more information 3) As a developer I want to run $GIT_DIR/hooks/ before $GIT_DIR/hooks/.d/* Reference: https://public-inbox.org/git/cacbzzx6j6q2dun_z-pnent1u714dvnpfbrl_pieqylmczlu...@mail.gmail.com/ The following story would be.. nice to have I think. I'm not sure I would want to implement this from the get go as I don't have a use case for it. 4) As a developer I want a way to have a hook report an error and let another hook decide if we want to pass or not. Reference: https://public-inbox.org/git/xmqq60v4don1@gitster.mtv.corp.google.com/ 2018-08-31 5:16 GMT+02:00 Jonathan Nieder : > A few unrelated thoughts, to expand on this. > > Separately from that, in [1] I mentioned that I want to revamp how > hooks work somewhat, to avoid the attack described there (or the more > common attack also described there that involves a zip file). Such a > revamp would be likely to also handle this multiple-hook use case. > > [1] > https://public-inbox.org/git/20171002234517.gv19...@aiede.mtv.corp.google.com/ The zip file attack vector doesn't change with adding a hook.d directory structure? If I have one file or multiple files, the attack stays the same? I think I'm asking if this would be a show stopper for the feature. Cheers, Wesley -- Wesley Schwengle, Developer Mintlab B.V., https://www.zaaksysteem.nl E: wes...@mintlab.nl T: +31 20 737 00 05
Re: Feature request: hooks directory
Ævar Arnfjörð Bjarmason wrote: > There is interest in this. This E-Mail of mine gives a good summary of > prior discussions about this: > https://public-inbox.org/git/877eqqnq22@evledraar.gmail.com/ > > I.e. it's something I've personally been interested in doing in the > past, there's various bolt-on solutions to do it (basically local hook > runners) used by various projects. A few unrelated thoughts, to expand on this. Reports of experience from using local hook runners would be very welcome so we can benefit from their good ideas and avoid their bad ones. That was part of the motivation for not building this in for so long: we want people to experiment so that the result can be something that works well for a lot of people. Separately from that, in [1] I mentioned that I want to revamp how hooks work somewhat, to avoid the attack described there (or the more common attack also described there that involves a zip file). Such a revamp would be likely to also handle this multiple-hook use case. As a word of caution, today we support having multiple credential helpers in use and it's a nightmare to support. The layering model is complicated and users don't understand it. So we might want to try to avoid whatever went wrong there. ;-) Thanks, Jonathan [1] https://public-inbox.org/git/20171002234517.gv19...@aiede.mtv.corp.google.com/
Re: feature request: allow commit.email config setting
On 2018-08-30 20:13, Eric Sunshine wrote: > On Thu, Aug 30, 2018 at 7:26 AM Rasmus Villemoes > wrote: >> I can set GIT_COMMITTER_EMAIL in the environment, but that is >> rather inconvenient, since that means I have to remember to do that in >> the shell I'm using for that particular project, and I can't use that >> shell for other projects. So it would be really nice if I could set >> commit.email = $private-email in the local .git/config for that >> particular project. > > Aside from modifying Git itself to support such a use-case, another > (perhaps more pragmatic) approach would be to use a tool, such as > direnv[1], which automatically sets environment variables for you > depending upon your current working directory, or just use some ad-hoc > shell programming to achieve the same (for instance, [2]). Thanks for the hint! I've actually had "git" as a function in my .bashrc for a long time, for implementing a ~/.githistory to help remember the sometimes rather complex git invocations, and keeping track of the context ($cwd, current branch, etc.) they were used in. It should be trivial to hook the environment settings based on $cwd into that. The only problem is that that gives me much less incentive to work on implementing the config support in git, but if I'm the only one with a use case, that's probably just as well. Rasmus
Re: feature request: allow commit.email config setting
On Thu, Aug 30, 2018 at 7:26 AM Rasmus Villemoes wrote: > I can set GIT_COMMITTER_EMAIL in the environment, but that is > rather inconvenient, since that means I have to remember to do that in > the shell I'm using for that particular project, and I can't use that > shell for other projects. So it would be really nice if I could set > commit.email = $private-email in the local .git/config for that > particular project. Aside from modifying Git itself to support such a use-case, another (perhaps more pragmatic) approach would be to use a tool, such as direnv[1], which automatically sets environment variables for you depending upon your current working directory, or just use some ad-hoc shell programming to achieve the same (for instance, [2]). [1]: https://direnv.net [2]: https://stackoverflow.com/questions/14462591/set-environmental-variables-in-a-particular-directory
Re: feature request: allow commit.email config setting
Rasmus Villemoes writes: > ... I can set GIT_COMMITTER_EMAIL in the environment, but that is > rather inconvenient, since that means I have to remember to do that in > the shell I'm using for that particular project, and I can't use that > shell for other projects. We only have user.email and user.name because nobody in the past 10+ years had such a requirement, but I find it it a perfectly sensible thing to wish to say "tagger.email and tagger.name are used while creating an annotated tag, committer.email and committer.name are used on the 'committer' line and author.email and author.name are used on the 'author' line in a newly created commit; by the way, if any of these are not set, but user.email or user.name is set, then they are used as fallback values." at the design level.
Re: Feature request: hooks directory
On Thu, Aug 30 2018, Wesley Schwengle wrote: > Hello all, > > I would like to ask if it is worth my time looking into the following > solution to a problem we have at work. > > Problem: > We want to have some git-hooks and we want to provide them to the > user. In a most recent example we have a post-checkout hook that deals > with some Docker things. However, if we update that post-checkout hook > my local overrides in that post-checkout hook are going to be > overwritten. > > Solution: > We discussed this at work and we thought about making a .d directory > for the hooks, eg. $GIT_DIR/hooks/post-commit.d, where a user can put > the post-commit hooks in. This allows us to provide post commit hooks > and allows the user to add additional hooks him/herself. We could > implement this in our own code base. But we were wondering if this > approach could be shared with the git community and if this behavior > is wanted in git itself. There is interest in this. This E-Mail of mine gives a good summary of prior discussions about this: https://public-inbox.org/git/877eqqnq22@evledraar.gmail.com/ I.e. it's something I've personally been interested in doing in the past, there's various bolt-on solutions to do it (basically local hook runners) used by various projects.
Re: Feature request: be able to pass arguments to difftool command
On Tue, 28 Aug 2018 12:37:40 -0700, Junio C Hamano wrote: > "H.Merijn Brand" writes: > > > So, my wish would be to have an option, possibly using -- to pass > > additional command line arguments to git difftool, so that > > > > $ git difftool $commit~1..$commit -- -m -v2 > > > > would pass the arguments after -- transparantly to ccdiff (in my case) > > At the syntax level passing any option after "--" would be a no > starter, as I would imagine that "git difftool $revs -- $paths" > should still be supported. > > At the concept level, however, I can see why such a feature would be > useful. Perhaps > > $ git difftool --backend-option=-m --backend-option=-v2 HEAD > $ git mergetool --backend-option=--foo This would mean I can just pass remaining arguments, like this? --8<--- ~/bin/git-ccdiff #!/usr/bin/env perl use 5.18.3; use warnings; my $commit; @ARGV && $ARGV[0] !~ m/^-/ and $commit = shift; my @git = qw( git difftool ); defined $commit and push @git, "$commit~1..$commit"; system @git, @ARGV; -->8--- > with appropriate way(s) [*1*] to make it easier to type (and > implement) would be an acceptable avenue to pursue, I wonder? I like it, as long as they are all separate options in the backend and not available in one single variable that needs to be split I can envision a configure variable like backends.options.separator = U+2063 so the backend can safely split on that itself. But I also see this as overly complex en over-engineering > [Footnote] > > *1* There are various possible ways, not all of them are mutually > incompatible. > > a. Give a short-form synonym, e.g. -X, to "--backend-option"; I like it > b. Assume that backend option always begins with a dash and add >one when missing, e.g. -Xm becomes --backend-option=-m I guess not: there might be tools that do not work like that, e.g. xfreerdp changed all their rememberable and logic options to the weird stupid syntax they use now, including mixing -, -- and + rdesktop -u user -p - -g 1280x1024 -a 16 -r clipboard:CLIPBOARD host -> xfreerdp -u user --from-stdin -g 1280x1024 -a 16 --plugin clipbrd host -> xfreerdp /u:user /from-stdin /size:1280x1024 /bpp:16 +clipboard /v:host > c. Allow giving multiple backend options on a single option and >split at whitespace, e.g. --backend-option="-m -v2" That is the weak part in my workaround, as it will break on options like --backend-option='--config="/path/to/My Configuration/My Application"' > d. Allow difftool.$toolname.opts configuration variable that is >multi-valued, so you can say > > git -c difftool.ccdiff.opts=-v2 -c difftool.ccdiff.opts=-m difftool Hmm, maybe harder to explain, but why not >(of course, not necessarily from the command line but the >point is you could configure it) > > Some of these (e.g. b, c) may not be desirable, though. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.29 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ pgpNDoJZUsEJo.pgp Description: OpenPGP digital signature
Re: Feature request: be able to pass arguments to difftool command
"H.Merijn Brand" writes: > So, my wish would be to have an option, possibly using -- to pass > additional command line arguments to git difftool, so that > > $ git difftool $commit~1..$commit -- -m -v2 > > would pass the arguments after -- transparantly to ccdiff (in my case) At the syntax level passing any option after "--" would be a no starter, as I would imagine that "git difftool $revs -- $paths" should still be supported. At the concept level, however, I can see why such a feature would be useful. Perhaps $ git difftool --backend-option=-m --backend-option=-v2 HEAD $ git mergetool --backend-option=--foo with appropriate way(s) [*1*] to make it easier to type (and implement) would be an acceptable avenue to pursue, I wonder? [Footnote] *1* There are various possible ways, not all of them are mutually incompatible. a. Give a short-form synonym, e.g. -X, to "--backend-option"; b. Assume that backend option always begins with a dash and add one when missing, e.g. -Xm becomes --backend-option=-m c. Allow giving multiple backend options on a single option and split at whitespace, e.g. --backend-option="-m -v2" d. Allow difftool.$toolname.opts configuration variable that is multi-valued, so you can say git -c difftool.ccdiff.opts=-v2 -c difftool.ccdiff.opts=-m difftool (of course, not necessarily from the command line but the point is you could configure it) Some of these (e.g. b, c) may not be desirable, though.
Re: Feature request : "git fsck" should show the percentage of completeness in step "Checking connectivity:"
On Sun, Jul 01, 2018 at 06:21:40PM +0200, Toralf Förster wrote:
> as "git fsck" does it already for "Checking objects:"
>
> Is this a valid feature request?
It's actually hard to do accurately. We don't know how many objects are
reachable until we traverse the graph...which is exactly what the
"checking connectivity" operation is doing.
The operation is bounded by the total number of objects in the
repository. We may have duplicates (in multiple packs, or loose/packed),
and objects which aren't reachable at all. But we could make that a
guess, and just "jump" to 100% at the end.
The code might look something like the patch below. I'm not sure if it's
a good idea or not (I mostly copied the counting from
builtin/count-objects.c; it might be nice to factor that out).
-Peff
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 3ad4f160f9..52e79aed76 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -192,17 +192,49 @@ static int traverse_one_object(struct object *obj)
return result;
}
+static int count_loose(const struct object_id *oid, const char *path,
+ void *data)
+{
+ unsigned int *nr = data;
+ nr++;
+ return 0;
+}
+
+static unsigned object_max(void)
+{
+ unsigned max = 0;
+ struct packed_git *p;
+
+ for_each_loose_object(count_loose, &max, 0);
+
+ for (p = get_packed_git(the_repository); p; p = p->next) {
+ if (open_pack_index(p))
+ continue;
+ max += p->num_objects;
+ }
+
+ return max;
+}
+
static int traverse_reachable(void)
{
struct progress *progress = NULL;
unsigned int nr = 0;
int result = 0;
- if (show_progress)
- progress = start_delayed_progress(_("Checking connectivity"),
0);
+ unsigned int max = 0;
+
+ if (show_progress) {
+ max = object_max();
+ progress = start_delayed_progress(_("Checking connectivity"),
+ max);
+ }
+
while (pending.nr) {
result |= traverse_one_object(object_array_pop(&pending));
display_progress(progress, ++nr);
}
+
+ display_progress(progress, max);
stop_progress(&progress);
return !!result;
}
Re: Feature request : "git fsck" should show the percentage of completeness in step "Checking connectivity:"
On Sun, Jul 1, 2018 at 9:22 AM Toralf Förster wrote:
>
> as "git fsck" does it already for "Checking objects:"
>
> Is this a valid feature request?
Yes it is. However it is most likely to have the feature incorporated if
it comes in form of a patch.
So clone one of the git.git repositories found at
https://git-blame.blogspot.com/p/git-public-repositories.html
and have a look builtin/fsck.c (Search for "Checking connectivity")
as well as how the progress.{h, c} for its API if needed.
I am not sure if this is an easy thing to add, as knowing the number
of objects before the walk might be hard. How does "Checking objects"
solve that issue?
See Documentation/SubmittingPatches once you have some code
that can be a starter of a discussion. :)
Thanks,
Stefan
Re: Feature Request: option for git difftool to show changes in submodule contents
Hi Oshaben! On Mon, Apr 23, 2018 at 7:49 AM, Oshaben Nicholas wrote: > Hello, > > A coworker of mine was trying to use git difftool in a repository with > submodules and we found that it only shows the change in the subproject > commit hash. The option to show the changes in the contents of the submodules > exists for git diff. Can this be added to difftool as well? Yes, of course it can be added. Care to write a patch? See lines 432-443 in builtin/difftool.c: https://github.com/git/git/blob/master/builtin/difftool.c#L432 I'd think you'd want to compute some output (Similar to the git-diff output? Then we could just refactor the submodule diff stuff to be reusable here) and put it into the strbuf there. Feel free to ask away or read the docs Documentation/SubmittingPatches Thanks, Stefan
Re: Feature Request: Add diff.word-diff and perhaps diff.word-diff-regex configuration options to enable always using word-diffs in git diff
Ævar Arnfjörð Bjarmason writes: > On Sat, Apr 14 2018, Doron Behar wrote: > >> I've just came across the wonderful command line option for `git diff`: >> `--word-diff`. It could be great to have a configuration option that >> will enable this feature by default when running `git diff`. > > Do you know you can do: > > git config --global alias.wdiff "diff --word-diff" Correct, but it is a "you could instead do it this way" that is not accompanied by a "you do not want to do what you said you want to because.." answer. Having the latter is often helpful to learn why the suggestion is actually not a mere "you could" but is a "you are better off doing it this way". Even though it is discouraged, people script using the Porcelain "git diff" command, and once users of such a configuration variable is used in Doron's fork of Git, those scripts will break for them. Using alias like you showed won't have such a problem.
Re: Feature Request: Add diff.word-diff and perhaps diff.word-diff-regex configuration options to enable always using word-diffs in git diff
On Sat, Apr 14 2018, Doron Behar wrote: > I've just came across the wonderful command line option for `git diff`: > `--word-diff`. It could be great to have a configuration option that > will enable this feature by default when running `git diff`. Do you know you can do: git config --global alias.wdiff "diff --word-diff" ?
Re: feature-request: git "cp" like there is git mv.
Stefan Moch writes: > Are such redundant checks in general a pattern worth searching > for and cleaning up globally? Or is this rather in the category > of cleaning up only when noticed? A clean-up patch that is otherwise a no-op is still welcome as it will improve the health of the codebase, but they become hindrances if there are too many of them to consume the review bandwidth that would otherwise be better spent on other non no-op topics, and/or if they add too many merge conflicts with other non no-op topics in flight. The amount of such negative impact a no-op clean-up patch can have on the project does not depend on how the issue was discovered, so we do not even have to know if the issue was discovered by actively hunting or by noticing while working on a near-by area. It is possible that by actively looking for, you may end up producing more of the no-op clean-up patches and can more easily interfere with other topics, which we may need to discourge or at least ask you to slow down. On the other hand, issues discovered while working on a near-by area would typically not increase conflicts with other topics in flight over the conflicts that would be caused by that real work you were doing in a near-by area already, so in that sense, "only when noticed" is a practical way to avoid the clean-up fatigue.
Re: feature-request: git "cp" like there is git mv.
* Junio C Hamano [2018-02-07T11:49:39-0800]:
> Stefan Moch writes:
>
> > * Jonathan Nieder [2017-12-15T17:31:30-0800]:
> >> This sounds like a reasonable thing to add. See builtin/mv.c for
> >> how "git mv" works if you're looking for inspiration.
> >>
> >> cmd_mv in that file looks rather long, so I'd also be happy if
> >> someone interested refactors to break it into multiple
> >> self-contained pieces for easier reading (git mostly follows
> >> https://www.kernel.org/doc/html/latest/process/coding-style.html#functions).
> >>
> >
> > I looked at builtin/mv.c and have a rough idea how to split it
> > up to support both mv and cp commands.
> >
> > But first I noticed and removed a redundant check in cmd_mv,
> > also added a test case to check if mv --dry-run does not move
> > the file.
>
> I guess these two patches went unnoticed when posted at the end of
> last year. Reading them again, I think they are good changes.
Thanks.
Are such redundant checks in general a pattern worth searching
for and cleaning up globally? Or is this rather in the category
of cleaning up only when noticed?
> As a no-op clean-up of a127331c ("mv: allow moving nested
> submodules", 2016-04-19), the attached would also make sense, I
> would think.
>
> Thanks.
>
> builtin/mv.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/mv.c b/builtin/mv.c
> index 9662804d23..9cb07990fd 100644
> --- a/builtin/mv.c
> +++ b/builtin/mv.c
> @@ -266,10 +266,11 @@ int cmd_mv(int argc, const char **argv, const
> char *prefix) const char *src = source[i], *dst = destination[i];
> enum update_mode mode = modes[i];
> int pos;
> - if (show_only || verbose)
> - printf(_("Renaming %s to %s\n"), src, dst);
> - if (show_only)
> + if (show_only) {
> + if (verbose)
> + printf(_("Renaming %s to %s\n"),
> src, dst); continue;
> + }
> if (mode != INDEX && rename(src, dst) < 0) {
> if (ignore_errors)
> continue;
>
As Stefan Beller already noted, this changes the printing
behavior:
See also the output of
git mv -n
git mv -n -v
git mv -v
without your patch:
$ git mv -n 1 2
Checking rename of '1' to '2'
Renaming 1 to 2
$ git mv -n -v 1 2
Checking rename of '1' to '2'
Renaming 1 to 2
$ git mv -v 1 2
Renaming 1 to 2
and with your patch:
$ git mv -n 1 2
Checking rename of '1' to '2'
$ git mv -n -v 1 2
Checking rename of '1' to '2'
Renaming 1 to 2
$ git mv -v 1 2
Having different outputs of “git mv -n” and “git mv -n -v” seems
odd, but not necessarily wrong. However, “git mv -v” with no
output at all, does not what the documentation says:
-v, --verbose
Report the names of files as they are moved.
