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 the
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 w
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.
>
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 gu
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
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:
> >
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
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 h
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 hotk
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
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+S
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 selec
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
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, w
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 th
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 sele
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 gi
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 g
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 ho
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
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+
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
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 uti
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 b
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
>
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 cl
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 forc
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 implem
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.
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?
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
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 permiss
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 wa
"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 regu
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
> fil
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
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
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 crea
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, t
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 o
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 for
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
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 serv
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
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 mess
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 comm
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 --one
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 wheth
Æ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
>> correc
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 refe
> 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.
>
> Th
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
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...@goo
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 t
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 a
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
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 o
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. :)
> >
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-opt
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. 'g
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
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
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 t
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 a
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
>
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
> wou
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
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
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 c
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 1
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 "s
Æ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-match
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
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 th
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
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
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 bra
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 s
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 alread
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 s
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 th
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 p
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
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'v
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 hoo
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
Æ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
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
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 i
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 us
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
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
"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 leve
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
"
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
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
Æ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
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
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, bu
* 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
1 - 100 of 472 matches
Mail list logo
