Re: [RFC/PATCH] Make --full-history consider more merges

Kevin Bracey ke...@bracey.fi writes: If simplify_history is set, and we do want ancestry, then it doesn't matter about the TREESAME definition because it shows all merges, regardless of the TREESAME flag. Thus adding --parents to the above command means it can find it, but only because it

Re: [PATCH] send-email: support NNTP

Thomas Rast tr...@inf.ethz.ch writes: Łukasz Stelmach l.stelm...@samsung.com writes: Enable sending patches to NNTP servers (Usenet, Gmane). I'm surprised Junio didn't mention this: your patch lacks the Signed-off-by. Heh, that was because I took the patch as an early preview and not a

Re: [BUG] Highly inconsistent diff UI

Junio C Hamano wrote: How is it different from git log master..rebase.autostash? git log A..B is already a perfectly fine way to spell your A~B, which is git log B --not $(git merge-base --all A B) when written in longhand [*1*], no? So I do not think your A~B helps log. They

Re: [PATCH] completion: remove duplicate block for git commit -c

This was caused by a mechanical mismerge at d931e2fb252e (Merge branch 'mp/complete-paths', 2013-02-08), it seems. The side branch fea16b47 wanted to add this block, of course, but the same fix was done independently in 685397585 already. Thanks for catching it. -- To unsubscribe from this

Re: [BUG] Highly inconsistent diff UI

Ramkumar Ramachandra wrote: Ofcourse, I now see that this is probably useless, and .. fits my bill. Would you find it potentially useful? You do a lot of merging back-and-fourth juggling feature branches, pu, next, master. When packaged with a good default for LHS (which .. currently doesn't

Re* [PATCH 5/7] git-log.txt: rewrite note on why -- may be required

Ramkumar Ramachandra artag...@gmail.com writes: In its current form, the note talks about separating options from branch names and refnames in the same sentence. This is entirely inaccurate, as revision range need not be a set of branch names or ref names. Rewrite it to use the word

Re: [RFC/PATCH] Make --full-history consider more merges

Junio C Hamano gits...@pobox.com writes: So, given all that, revised patch below: I tried to squeeze the minimum test I sent $gmane/220919 to the test suite. I think the do not use --parents option for this test switch needs to be cleaned up a bit more, but it fails without your patch and does

Fw:9 ปี กรือเซะ 28 เมษายน 2556

9 ปี กรือเซะ 28 เมษายน 2556 ย้อนกลับไปดูเหตุการณ์ เมื่อวันที่ 28 เมษายน 2547 เกิดความ รุนแรงขึ้นที่จังหวัดชายแดนภาคใต้ถึง 11 จุด ในวันเดียวกัน แต่เหตุการณ์ที่ ต้องจดจำกันไปอีกนานก็คือ กรณีเหตุการณ์ที่มัสยิดกรือเซะ จังหวัดปัตตานี

Re: [PATCH] bisect: Store first bad commit as comment in log file

From: Torstein Hegge he...@resisty.net Subject: Re: [PATCH] bisect: Store first bad commit as comment in log file Date: Tue, 23 Apr 2013 00:20:58 +0200 On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote: Torstein Hegge he...@resisty.net writes: I took another look at this. I

Re: [BUG] Highly inconsistent diff UI

Ramkumar Ramachandra wrote: We might still want it. I mean what are we losing? Actually, let's just look at extending the rev specs we currently have. I'll gather up a list of real itches and post it to the list. -- To unsubscribe from this list: send the line unsubscribe git in the body of a

Itches with the current rev spec

Hi, So, I have three serious itches that would be nice to address: 1. git reset --hard HEAD~1/ git show HEAD~1 is a very common idiom that's unnecessarily cumbersome to type out. We can make the rev part of rev~n optional without being ambiguous: you might argue that ~n normally refers to a

Re: Re* [PATCH 5/7] git-log.txt: rewrite note on why -- may be required

Junio C Hamano wrote: It should be more like this [*1*]: 'git log' [options] [revision range] [--] [path...] Agreed. The backslash is unnecessary (I suspect it's something carried over from earlier versions of asciidoc requiring this escaping). It may be better to split the item

Re: Itches with the current rev spec

Ramkumar Ramachandra wrote: 3. Even though I lashed out strongly against 'git diff A..B' because of inconsistency, I can't say that it's not useful (omit specifying HEAD on one side). If we were to start over today, I would argue that 'git diff A ^B' and 'git diff B ^A' be handled as special

[PATCH] git-remote-testgit: avoid process substitution

From: Johannes Sixt j...@kdbg.org Bash on Windows does not implement process substitution. Signed-off-by: Johannes Sixt j...@kdbg.org --- Am 4/24/2013 10:30, schrieb Johannes Sixt: Am 4/24/2013 10:04, schrieb Felipe Contreras: On Wed, Apr 24, 2013 at 2:57 AM, Johannes Sixt j.s...@viscovery.net

Re: [BUG] Highly inconsistent diff UI

Ramkumar Ramachandra artag...@gmail.com writes: Ramkumar Ramachandra wrote: Ofcourse, I now see that this is probably useless, and .. fits my bill. Would you find it potentially useful? I dunno. The description you gave was insufficient for me to answer that question. The part of your

<    1   2