Re: Git reset --hard with staged changes

From: Pierre-François CLEMENT gmail.com> > You create a new (untracked) file. > You use git-reset's hard mode to go one commit back, the new > (untracked) file's still there. > You add/stage that new file. > You use git-reset's hard mode again to go one commit back, and the new > untracked file yo

Re: Bug: Failure if stdin is closed.

> From: Thomas Rast > May I ask why you need this, and to what extent this problem cannot be > solved by instead redirecting from/to /dev/null? The situation in which the problem arose is described here: > wor...@alum.mit.edu (Dale R. Worley) writes: > > > (The original problem and the discuss

[PATCHv3] CodingGuidelines: Documentation/*.txt are the sources

People not familiar with AsciiDoc may not realize they are supposed to update *.txt files and not *.html/*.1 files when preparing patches to the project. Signed-off-by: Dale Worley --- Documentation/CodingGuidelines |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a

Re: "git rebase" loses the additional changes in "evil" merges

> From: Junio C Hamano > > I think this is to be expected for "git rebase", as it does not even > look at merges. It is a way to find non-merge commits that haven't > been applied yet, and apply them to the upstream to create a new > linear history. I disagree. "git rebase" is not characterized