Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Jan Smets writes: > Hi > > I've recently expired my reflog to prune loose objects. On a live, > bare, repository I ran 'git gc --prune=now' > > All clients ended up having problems, they would report: > error: refs/heads/master does not point to a valid object! >

Alternative to manual editing with git add --patch

Hello, I hope this hasn't been discussed before. I'm a big fan of cleanliness in commits and therefore often use git add --patch to sort code changes I made into the right commits etc. What I then often encountered was the situation where I happened to have inserted consecutive lines of code

Re: [BUG] Broken links in Git Documentation/user-manual.txt

John Keeping writes: > On Wed, Oct 14, 2015 at 09:37:05AM +0200, Matthieu Moy wrote: >> Xue Fuqiao writes: >> >> > Hi list, >> > >> > In https://git-scm.com/docs/user-manual.html , all links to the >> > glossary[1] are broken. >> >> Actually, the links

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Junio C Hamano writes: > diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt > index 5223498..fa15104 100644 > --- a/Documentation/git-gc.txt > +++ b/Documentation/git-gc.txt > @@ -63,8 +63,11 @@ automatic consolidation of packs. > --prune=:: > Prune loose

Re: Alternative to manual editing with git add --patch

Hi Sven, On 2015-10-14 17:07, Sven Helmberger wrote: > What I then often encountered was the situation where I happened to have > inserted consecutive lines of code that conceptually belong to different > commits. Normally I can nicely split patches, but not in this case, > making manually

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Jan Smets writes: > 2) > > remote: error: unable to write sha1 filename > objects/05/cdb51bb0ea3e229734a4b1bddd5ec70fbc65ed: No such file or > directory > remote: fatal: failed to write object If I read correctly, this happens when we move the temp file to its

[PATCH 1/2] contrib: Add git-candidate subcommand

git-candidate provides candidate review and patch tracking, allowing distributed comment and review facilities with all content stored in git. Signed-off-by: Richard Ipsum --- contrib/git-candidate/GitUtils.pm| 215 +++

[RFC] Git based patch tracking and review

Hi, I've been working to add patch tracking and candidate review to git. The motivation for this is simply that most patch tracking systems are centralised, since git is a distributed vcs it seems appropriate that patches, reviews and comments should also be distributed. The system aims to be

[PATCH 2/2] contrib/git-candidate: Add README

Describes motivation for git-candidate and shows an example workflow. Signed-off-by: Richard Ipsum --- contrib/git-candidate/README.md | 153 1 file changed, 153 insertions(+) create mode 100644

Re: Alternative to manual editing with git add --patch

Sven Helmberger writes: > I hope this hasn't been discussed before. > > I'm a big fan of cleanliness in commits and therefore often use git add > --patch to sort code changes I made into the right commits etc. > > What I then often encountered was the situation where I

Re: Alternative to manual editing with git add --patch

Sven Helmberger writes: > Hello, > > I hope this hasn't been discussed before. > > I'm a big fan of cleanliness in commits and therefore often use git add > --patch to sort code changes I made into the right commits etc. > > What I then often encountered was the situation

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Matthieu Moy writes: > I think this is the expected behavior. push will create new objects that > are not referenced until the ref is updated (at the very end). prune can > run concurrently since creating and deleting objects is done in a > lockless way (only the

Re: [PATCH v2 08/10] ref-filter: add support for %(upstream:track,nobracket)

Wed, Oct 14, 2015 at 12:24 AM, Matthieu Moy wrote: > Yes, but I still think that this was a bad idea. If you want nobracket > to apply to "track", then the syntax should be > %(upstream:track=nobracket). I think the "nobracket" should apply to > "upstream" (i.e. be

Re: [BUG] Broken links in Git Documentation/user-manual.txt

Xue Fuqiao writes: > Hi list, > > In https://git-scm.com/docs/user-manual.html , all links to the > glossary[1] are broken. Actually, the links themselves are fine, but the destimation is broken. The doc is supposed to look like this :

Re: [PATCH 1/1] send-email: allow to compose only prepared cover letter

On Tue, 2015-10-13 at 14:11 -0700, Junio C Hamano wrote: > Andy Shevchenko writes: > > > My often use case is to do: > > % git format-patch --cover-letter --subject-prefix="PATCH > > vN" rev1^..revXYZ > > % $GIT_EDITOR -* > > % git send-email

[ANNOUNCE] Git Rev News edition 8

Hi everyone, I'm happy announce that the 8th edition of Git Rev News is now published: https://git.github.io/rev_news/2015/10/14/edition-8/ Thanks a lot to all the contributors! Enjoy, Christian, Thomas and Nicola. -- To unsubscribe from this list: send the line "unsubscribe git" in the body

Captain Kelvin Ken Miller

Am Captain Kelvin Ken Miller currently I need you assistant to move some funds out of Iraq. Kindly respond for more details. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH 02/26] mailinfo: fix for off-by-one error in boundary stack

On Tue, Oct 13, 2015 at 4:16 PM, Junio C Hamano wrote: > We pre-increment the pointer that we will use to store something at, > so the pointer is already beyond the end of the array if it points > at content[MAX_BOUNDARIES]. > > Signed-off-by: Junio C Hamano

Re: [PATCH 02/26] mailinfo: fix for off-by-one error in boundary stack

I'll be sending out v2 very soon, so you might want to hold off for a few minutes. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH v2 17/31] mailinfo: move transfer_encoding to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 27 ++- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 00b8b4b..140b31ee 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@

[PATCH v2 12/31] mailinfo: move filter/header stage to struct mailinfo

Earlier we got rid of two function-scope static variables that kept track of the states of helper functions by making them extra arguments that are passed throughout the callchain. Now we have a convenient place to store and pass them around in the form of "struct mailinfo", change them into two

[PATCH v2 28/31] mailinfo: libify

Move the bulk of the code from builtin/mailinfo.c to mailinfo.c so that new callers can start calling mailinfo() directly. Note that a few calls to exit() and die() need to be cleaned up for the API to be truly useful, which will come in later steps. Signed-off-by: Junio C Hamano

[PATCH v2 26/31] mailinfo: move cleanup_space() before its users

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 25 +++-- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index ee669b9..f4771ee 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -41,8

[PATCH v2 16/31] mailinfo: move metainfo_charset to struct mailinfo

This requires us to pass the struct down to decode_header() and convert_to_utf8() callchain. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 40 +++- 1 file changed, 19 insertions(+), 21 deletions(-) diff --git a/builtin/mailinfo.c

[PATCH v2 15/31] mailinfo: move use_scissors and use_inbody_headers to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 6703453..80034a2 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -20,6

[PATCH v2 11/31] mailinfo: move global "FILE *fin, *fout" to struct mailinfo

This requires us to pass "struct mailinfo" to more functions throughout the codepath that read input lines, which makes later steps easier. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 54 -- 1 file changed, 28

[PATCH v2 09/31] mailinfo: introduce "struct mailinfo" to hold globals

Initially have only 'email' and 'name' fields in there and remove the corresponding globals. In subsequent patches, more globals will be moved to this and the structure will be passed around as a new parameter to more functions. Signed-off-by: Junio C Hamano ---

[PATCH v2 10/31] mailinfo: move keep_subject & keep_non_patch_bracket to struct mailinfo

These two are the only easy ones that do not require passing the structure around to deep corners of the callchain. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/builtin/mailinfo.c

[PATCH v2 22/31] mailinfo: keep the parsed log message in a strbuf

When mailinfo() is eventually libified, the calling "git am" still will have to write out the log message in the "msg" file for hooks and other users of the information, but at least it does not have to reopen and reread what was written back if the function kept it in a strbuf so that the caller

[PATCH v2 30/31] mailinfo: remove calls to exit() and die() deep in the callchain

The top-level mailinfo() would instead punt when the code in the deeper part of the callchain detects an unrecoverable error in the input. Signed-off-by: Junio C Hamano --- mailinfo.c | 30 ++ mailinfo.h | 1 + 2 files changed, 23 insertions(+), 8

[PATCH v2 08/31] mailinfo: move global "line" into mailinfo() function

With the pregvious step, it becomes clear that the mailinfo() function is the only one that wants the "line_global" to be directly touchable. Logically, this strbuf belongs to handle_body(). It passes the line to its helper functions for processing, and keeps one line at a time into the variable

[PATCH v2 25/31] mailinfo: move check_header() after the helpers it uses

This way, we can lose a forward decl for decode_header(). Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 139 ++--- 1 file changed, 69 insertions(+), 70 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c

[PATCH v2 31/31] am: make direct call to mailinfo

And finally the endgame. Instead of spawning "git mailinfo" via the run_command() API the same number of times as there are incoming patches, make direct internal call to the libified mailinfo() from "git am" to reduce the spawning overhead, which would matter on some platforms. Signed-off-by:

[PATCH v2 14/31] mailinfo: move add_message_id and message_id to struct mailinfo

This requires us to pass the structure into check_header() codepath. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 30 -- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index

[PATCH v2 29/31] mailinfo: handle charset conversion errors in the caller

Instead of dying in convert_to_utf8(), just report an error and let the callers handle it. Between the two callers: - decode_header() silently punts when it cannot parse a broken RFC2047 encoded text (e.g. when it sees anything other than B or Q after it sees "=?") by jumping to

[PATCH v2 27/31] mailinfo: move definition of MAX_HDR_PARSED to closer to its use

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index f4771ee..de446ec 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -39,8 +39,6 @@ struct mailinfo

[PATCH v2 13/31] mailinfo: move patch_lines to struct mailinfo

This one is trivial thanks to previous steps that started passing the structure throughout the input codepaths. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/builtin/mailinfo.c

[PATCH v2 03/31] mailinfo: explicitly close file handle to the patch output

This does not make a difference within the context of "git mailinfo" that runs once and exits, as flushing and closing would happen upon process completion. It however will matter when we eventually make this function callable as an API function. Besides, cleaning after yourself once you are

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Junio C Hamano writes: > Matthieu Moy writes: > >> This looks like a race between deleting objects/05/ and creating >> objects/05/cdb51bb0ea3e229734a4b1bddd5ec70fbc65ed. >> >> I don't understand how this is possible, since the temporary file and

Re: [PATCH 06/26] mailinfo: always pass "line" as an argument

On Tue, Oct 13, 2015 at 4:16 PM, Junio C Hamano wrote: > Some functions in this module accessed the global "struct strbuf > line" while many others used a strbuf passed as an argument. > Convert the former to ensure that nobody deeper in the callchains > relies on the global

Re: [PATCH 07/26] mailinfo: move global "line" into mailinfo() function

On Tue, Oct 13, 2015 at 4:16 PM, Junio C Hamano wrote: > The mailinfo() function is the only one that wants the "line_global" > to be directly touchable. Note that handle_body() has to be passed > this strbuf so that it sees the "first line of the input" after the > loop in

Re: [PATCH 06/26] mailinfo: always pass "line" as an argument

Stefan Beller writes: >> @@ -1019,10 +1019,10 @@ static int mailinfo(FILE *in, FILE *out, const char >> *msg, const char *patch) >> ungetc(peek, in); >> >> /* process the email header */ >> - while (read_one_header_line(, fin)) >> -

[PATCH v2 04/31] mailinfo: fold decode_header_bq() into decode_header()

In olden days we might have wanted to behave differently in decode_header() if the header line was encoded with RFC2047, but we apparently do not do so, hence this helper function can go, together with its return value. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c |

[PATCH v2 23/31] mailinfo: move content/content_top to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 45 ++--- 1 file changed, 26 insertions(+), 19 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 72668c9..138ca3b 100644 --- a/builtin/mailinfo.c +++

[PATCH v2 07/31] mailinfo: always pass "line" as an argument

Some functions in this module accessed the global "struct strbuf line" while many others used a strbuf passed as an argument. Convert the former to ensure that nobody deeper in the callchains relies on the global one. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 48

[PATCH v2 00/31] libify mailinfo and call it directly from am

During the discussion on the recent "git am" regression, I noticed that the command reimplemented in C spawns one "mailsplit" and then spawns "mailinfo" followed by "apply --index" to commit the changes described in each message. As there are platforms where spawning subprocess via run_command()

[PATCH v2 19/31] mailinfo: handle_commit_msg() shouldn't be called after finding patchbreak

There is a strange "if (!cmitmsg) return 0" at the very beginning of handle_commit_msg(), but the condition should never trigger, because: * The only place cmitmsg is set to NULL is after this function sees a patch break, closes the FILE * to write the commit log message and returns 1.

[PATCH v2 20/31] mailinfo: move cmitmsg and patchfile to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index f48a260..5809e13 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@

[PATCH v2 02/31] mailinfo: fix for off-by-one error in boundary stack

We pre-increment the pointer that we will use to store something at, so the pointer is already beyond the end of the array if it points at content[MAX_BOUNDARIES]. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Matthieu Moy writes: > Looks good to me. I think the same should be added to git-prune.txt > under --expire. I thought about it, but decided against it, as the command is not even recommended to end users. -- To unsubscribe from this list: send the line

[PATCH v2 01/31] mailinfo: remove a no-op call convert_to_utf8(it, "")

The called function checks if the second parameter is either a NULL or an empty string at the very beginning and returns without doing anything. Remove the useless call. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 5 - 1 file changed, 5 deletions(-) diff

[PATCH v2 21/31] mailinfo: move [ps]_hdr_data to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 5809e13..aa17c77 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@

[PATCH v2 18/31] mailinfo: move charset to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 140b31ee..41f659d 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -22,6 +22,7 @@

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Matthieu Moy writes: > This looks like a race between deleting objects/05/ and creating > objects/05/cdb51bb0ea3e229734a4b1bddd5ec70fbc65ed. > > I don't understand how this is possible, since the temporary file and > the final one are in the same directory, so

[PATCH v2 06/31] mailinfo: get rid of function-local static states

Two helper functions use "static int" in their scope to keep track of the state while repeatedly getting called once for each input line. Move these state variables their ultimate caller and pass down pointers to them, as a small step in preparation for making this entire callchain more

[PATCH v2 05/31] mailinfo: move handle_boundary() lower

This function wants to call find_boundary() and is called only from one place without any recursing, so it becomes easier to read if it appears after the called function. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 114

[PATCH v2 24/31] mailinfo: move read_one_header_line() closer to its callers

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 132 ++--- 1 file changed, 66 insertions(+), 66 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 138ca3b..0b083d0 100644 --- a/builtin/mailinfo.c +++

Re: [PATCH v2] merge: fix cache_entry use-after-free

David Turner writes: > + unsigned int ref_count; /* count the number of refs to this in dir_hash > */ Me makes a mental note of the type used... > @@ -213,6 +214,32 @@ struct cache_entry { > struct pathspec; > > /* > + * Increment the cache_entry reference

[PATCH] Tracing commands includes its working directory

Specially when having concurrent flows of command execution, the order of commands printed cannot be relied upon. To aid the poor developer follow the flow of commands include the current working directory in which the command is carried out. Signed-off-by: Stefan Beller ---

What's cooking in git.git (Oct 2015, #03; Wed, 14)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. With somewhat reduced review bandwidth, I'd expect that the upcoming cycle would be slower than usual. At tinyurl.com/gitCal, I tentatively

Re: [PATCH v3 1/3] Add Travis CI support

On 12 Oct 2015, at 22:20, Matthieu Moy wrote: > larsxschnei...@gmail.com writes: > >> --- /dev/null >> +++ b/.travis.yml >> @@ -0,0 +1,46 @@ >> +language: c >> + >> +os: >> + - linux >> + - osx >> + >> +compiler: >> + - clang >> + - gcc >> + >>

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Junio C Hamano writes: > Matthieu Moy writes: > >> Looks good to me. I think the same should be added to git-prune.txt >> under --expire. > > I thought about it, but decided against it, as the command is not > even recommended to end users. Even

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Matthieu Moy writes: > Junio C Hamano writes: > >> Matthieu Moy writes: >> >>> Looks good to me. I think the same should be added to git-prune.txt >>> under --expire. >> >> I thought about it, but decided against

Re: [PATCH v2] merge: fix cache_entry use-after-free

On Wed, 2015-10-14 at 14:17 -0700, Junio C Hamano wrote: > David Turner writes: > > > + unsigned int ref_count; /* count the number of refs to this in dir_hash > > */ > > Me makes a mental note of the type used... > > > @@ -213,6 +214,32 @@ struct cache_entry { > >

Re: [PATCH] Tracing commands includes its working directory

Stefan Beller writes: > Specially when having concurrent flows of command execution, > the order of commands printed cannot be relied upon. To aid > the poor developer follow the flow of commands include the > current working directory in which the command is carried out. > >

[PATCH v3] merge: fix cache_entry use-after-free

From: Keith McGuigan During merges, we would previously free entries that we no longer need in the destination index. But those entries might also be stored in the dir_entry cache, and when a later call to add_to_index found them, they would be used after being freed. To

Re: [PATCH v2 20/31] mailinfo: move cmitmsg and patchfile to struct mailinfo

This step does not compile correctly; will be fixed in v3. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 21/31] mailinfo: move [ps]_hdr_data to struct mailinfo

Junio C Hamano writes: > @@ -995,10 +995,10 @@ static int mailinfo(struct mailinfo *mi, const char > *msg, const char *patch) > > /* process the email header */ > while (read_one_header_line(, mi->input)) > - check_header(mi, , p_hdr_data, 1); > +

Re: [PATCH] git-gui: Update Russian translation

Dimitriy Ryazantcev writes: >Signed-off-by: Dimitriy Ryazantcev >--- > po/ru.po | 675 +++ > 1 file changed, 247 insertions(+), 428 deletions(-) > >diff --git a/po/ru.po

RE: thread-utils: build with NO_PTHREADS fails

Hello Junio, sorry that was my fault, I was building it wrong way (defined NO_PTHREADS in CFLAGS variable, not as separate make variable). Sorry for the false alarm. -- Best Regards, Victor From: Junio C Hamano [jch2...@gmail.com] On Behalf Of Junio C

Re: [BUG] Broken links in Git Documentation/user-manual.txt

On Wed, Oct 14, 2015 at 09:37:05AM +0200, Matthieu Moy wrote: > Xue Fuqiao writes: > > > Hi list, > > > > In https://git-scm.com/docs/user-manual.html , all links to the > > glossary[1] are broken. > > Actually, the links themselves are fine, but the destimation is broken. >

Re: [PATCH v3] merge: fix cache_entry use-after-free

Am 15.10.2015 um 00:07 schrieb David Turner: From: Keith McGuigan During merges, we would previously free entries that we no longer need in the destination index. But those entries might also be stored in the dir_entry cache, and when a later call to add_to_index found

[PATCH] Falis on commit --amend when already pushed

Hello all, I'm a third year student at the University of Tokyo and, in our "Diving into open-source software" class, my friends and I decided to work with git. Our final, hopefully, is contributing to git. One improvement that we thought of was not letting users to amend commit when the commit

[PATCH v2] git-gui: Update Russian translation

>This section seems wrong as it replaces the existing copyright notice >with some auto-generated junk. As it is a translation I should think the >copyright is with the translators but it should not be using default >placeholders. Sorry for that. It seems that a Transifex bug, I uploaded po with

[Bug?] .git visible in git-status

I've recently stumbled upon interesting issue - .git/* files occurring in the git-status output. Let me elaborate: 1. When running > git status -s no .git/* files are displayed 2. When running: > git status -s .git only an empty line is printed out 3. But when I run (for example): > git status -s

Captain Kelvin Ken Miller

Am Captain Kelvin Ken Miller i am with the us army in Camp Abu Naji / FOB Garry Owen (Al Amarah)I need you assistant to move some funds out of Iraq. Kindly respond for more details. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

repository corruption when pushing commits to a repository running 'git gc --prune='

Hi I've recently expired my reflog to prune loose objects. On a live, bare, repository I ran 'git gc --prune=now' All clients ended up having problems, they would report: error: refs/heads/master does not point to a valid object! Running 'git log' on the bare repo gave : fatal: bad object

Re: Alternative to manual editing with git add --patch

Am 14.10.2015 um 19:50 schrieb Junio C Hamano: > Sven Helmberger writes: > > As a quick-and-dirty change, you could invent a new variant of > 's'plit that breaks a N-line hunk into N hunks with 1-line each, but > obviously that would not be a pleasant-enough UI to be