Automating git add & commit for every change individually?

Hi, Not sure this is the right place; I couldn't find a mailing list specifically for git *users*? Problem: Given two source trees, neither yet under source control. One (hereafter:MOD)containing extensive modifications of the other (hereafter:ORIG), I want to bring these together under

Re: Git log three-dot notation: include merge base

On Sat, May 14, 2016 at 6:30 PM, Junio C Hamano wrote: > Robert Dailey writes: > >> This is because the merge base commit isn't shown. I understand this >> is "by-design", but is there a way to include it? It's necessary to >> have it, for this graph

Re: Git log three-dot notation: include merge base

Robert Dailey writes: > This is because the merge base commit isn't shown. I understand this > is "by-design", but is there a way to include it? It's necessary to > have it, for this graph to make sense. --boundary, perhaps? -- To unsubscribe from this list: send the

Re: Git log three-dot notation: include merge base

On Sat, May 14, 2016 at 06:09:21PM -0500, Robert Dailey wrote: > Using A...B notation, I get this: > > $ git log --oneline --decorate --graph A...B > * eb28ae4 (HEAD -> B) Commit 6 > * 7173fa1 Commit 5 > * b5fe27b Commit 4 > * 37a8ca8 (A) Commit 3 > * 72745a7 Commit 2 > > The graph no longer

Git log three-dot notation: include merge base

If you consider a simple case where I run the following command: $ git log --oneline --graph --decorate A...B Where A and B are both branches with a single merge base and a series of commits on each branch. Very simple example with no loops or crazy ancestry. Below is an example repo I set up,

Re: [PATCH 3/6] t9107: use "return 1" instead of "exit 1"

On Sat, May 14, 2016 at 10:37:07AM -0700, Junio C Hamano wrote: > Thanks for sharp eyes. Let's squash this in, perhaps? > > t/t9107-git-svn-migrate.sh | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/t/t9107-git-svn-migrate.sh b/t/t9107-git-svn-migrate.sh > index

Re: [PATCH v2 00/94] libify apply and use lib in am

On Sat, May 14, 2016 at 8:31 PM, Junio C Hamano wrote: > > I however do not see a reason why you need to expose that feature to > the users of "git apply". So I am not sure if any of us care deeply > the choice among --silent, --quiet and -q -q. About that I wrote in initial

Re: [PATCH 5/5] pathspec: record labels

Stefan Beller writes: > Labels were originally designed to manage large amount of > submodules, the discussion steered this in a more general > direction, such that other files can be labeled as well. s/other files/any path/. > Labels are meant to describe arbitrary set of

Re: Empty config sections are neither deleted nor reused

Junio C Hamano writes: > Matthieu Moy writes: > >> Junio's explanation must not necessarily be read as "it has to be the >> way it is", but more as "getting it right is harder than you think", and >> that in turn explains why no one changed the

Re: [PATCH] crlf: Add test showing double warning on commit

Torsten Bögershausen writes: > Do we need to run diff_populate_filespec() twice when src==dst ? Of course we do. src and dst may have the same path, but are coming from different places (src may be an indexed blob while dst may be a file in the working tree). > If yes, we may

Re: 'git diff-index' doesn't honor the 'diff.algorithm' variable

Dmitry Gutov writes: > Hi all, > > Subj. ...even though it's explicitly mentioned in the subcommand's man > page. Git version 2.7.4 here. > > To elaborate: > > - Call 'git config --global diff.algorithm histogram'. The variable belongs to UI config, meant for Porcelain "git

Re: [PATCH v2 00/94] libify apply and use lib in am

Christian Couder writes: >>> So it looks to me that --quiet means something like "don't tell the >>> story of your life, but in case of problem you are allowed to >>> complain". In other word --quiet generally doesn't suppress error >>> messages from error() or die().

Re: [PATCH v2 48/94] builtin/apply: rename 'prefix_' parameter to 'prefix'

Christian Couder writes: > On Thu, May 12, 2016 at 10:43 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> Up to this point, the conversion looks quite sensible, even though I >>> think the organization of fields in

Re: [BUG] t9801 and t9803 broken on next

Lars Schneider writes: >> On 13 May 2016, at 18:37, Junio C Hamano wrote: >> >> Are you saying that "git p4" itself breaks unless fast-import always >> writes a new (tiny) packfile? That sounds quite broken, and setting >> unpacklimit to 0 does not

Re: [PATCH 3/6] t9107: use "return 1" instead of "exit 1"

Jeff King writes: > On Fri, May 13, 2016 at 07:45:42PM -0400, Eric Sunshine wrote: > >> > + >expect && >> >> What's this 'expect' file for? Is it leftover gunk from before you >> settled on 'diff --exit-code'? > > Oops, yes, that's exactly it. > > -Peff Thanks for sharp

Re: Empty config sections are neither deleted nor reused

Matthieu Moy writes: > Junio's explanation must not necessarily be read as "it has to be the > way it is", but more as "getting it right is harder than you think", and > that in turn explains why no one changed the behavior. Thanks for clarification. s/must not

Subtree split unsquashes everything

Hello! I was directed to ask here; I hope I am respecting your format. I have a repo with a subtree. I squashed every merge with the subtree remote to keep the history manageable. Now down the road after a bunch of merges, I need to split my repo’s master branch into two new branches and move the

Re: Empty config sections are neither deleted nor reused

Jonas Bernoulli writes: >> The configuration sections can have comments and they are preserved >> even when they become empty. Adding something unrelated will still >> make it appear the stale comment applies to it. > > Now that you mention it, I think I have read that before.

Git and Mozaik

Hi Everyone, I'm embarking on a bit of a quest to bring git into a CNC manufacturing environment for the Mozaik software package. Does anyone in the group have experience with git for that package (expecting probably not, but I had to ask)? I'm hoping that there won't be too many problems

Re: Empty config sections are neither deleted nor reused

> The configuration sections can have comments and they are preserved > even when they become empty. Adding something unrelated will still > make it appear the stale comment applies to it. Now that you mention it, I think I have read that before. Unfortunately I forgot about it until you

Re: [PATCH v10 00/20] index-helper/watchman

On do, 2016-05-12 at 16:19 -0400, David Turner wrote: > This version fixes that.  I didn't test on a virtual machine, but I > did test by adding a sleep(). I can confirm that on my single-cpu test VM, this no longer triggers errors. D. -- To unsubscribe from this list: send the line

Re: What's cooking in git.git (May 2016, #05; Fri, 13)

On Sat, May 14, 2016 at 3:41 AM, Junio C Hamano wrote: > * pb/bisect (2016-05-13) 4 commits > - t6030: explicitly test for bisection cleanup This one can be considered as independent of the entire series. > - bisect--helper: `write_terms` shell function in C > - bisect:

PAYMENT

Congratulations, You may not understand why this letter came to you. We have been having a meeting for quit sometime now and we just came to a logical conclusion few days ago in affiliation with the World Bank president. This letter is to few well listed people that have been scammed

[PATCH] crlf: Add test showing double warning on commit

Add failing test case showing CRLF -> LF rewrite warnings being printed multiple times when running "git commit". Signed-off-by: Adam Dinwoodie --- t/t0020-crlf.sh | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/t/t0020-crlf.sh

Re: Bug report: Duplicate CRLF rewrite warnings on commit

On Sat, May 14, 2016 at 07:40:11AM +0200, Torsten Bögershausen wrote: > On 13.05.16 18:43, Junio C Hamano wrote: > > Adam Dinwoodie writes: > > > >> If you use .gitattributes to enable CRLF->LF rewriting, then commit a > >> file that would have its line endings rewritten, the

Re: [PATCH v2 00/94] libify apply and use lib in am

On Sat, May 14, 2016 at 8:26 AM, Johannes Schindelin wrote: [...] >> >> By the way there are no tests yet for this new feature, and I am not >> >> sure at all that "--silent" and "be_silent" are good names. >> > >> > If you want to follow existing code's example, we

Re: [PATCH v2 29/33] refs: resolve symbolic refs first

On 13.05.16 14:33, Michael Haggerty wrote: > Torsten, thanks for the report. Peff, thanks for the analysis. I didn't follow all the details. The new "pu" passes with no errors on all of my test systems :-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a

Re: [BUG] t9801 and t9803 broken on next

> On 13 May 2016, at 18:37, Junio C Hamano wrote: > > Eric Wong writes: > >> Lars Schneider wrote: >>> Hi, >>> >>> t9801 and t9803 seem to be broken on next. A quick bisect indicates that >>> d9545c7 >>> "fast-import: implement

Re: [PATCH v2 00/94] libify apply and use lib in am

Hi Chris, On Fri, 13 May 2016, Christian Couder wrote: > On Fri, May 13, 2016 at 8:32 AM, Johannes Schindelin > wrote: > > > > On Wed, 11 May 2016, Christian Couder wrote: > > > >> I consider that the apply functionality is properly libified before > >> these