Re: [RFC PATCH] Introduce "precious" file concept

On Tue, Nov 27, 2018 at 1:45 AM Per Lundberg wrote: > > On 11/26/18 5:55 PM, Duy Nguyen wrote: > > On Mon, Nov 26, 2018 at 4:47 PM Ævar Arnfjörð Bjarmason > > wrote: > >> Some of the solutions overlap with this thing you want, but I think it's > >> worth keeping the distinction between the two

Re: git log -S or -G

On Mon, Oct 8, 2018 at 8:22 PM Jeff King wrote: > > On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote: > > > Julia Lawall writes: > > > > >> Doing the same for -S is much harder at the machinery level, as it > > >> performs its thing without internally running "diff" twice, but just

Re: [PATCH v3] coccicheck: process every source file at once

On Fri, Oct 5, 2018 at 12:00 PM Jeff King wrote: > That's OK, too, assuming people would actually want to use it. I'm also > OK shipping this (with the "make -j" fix you suggested) and seeing if > anybody actually complains. I assume there are only a handful of people > running coccicheck in the

Re: [PATCH 1/1] rebase -i: introduce the 'break' command

On Fri, Oct 5, 2018 at 1:17 AM Junio C Hamano wrote: > If one wants to emulate this with the versions of Git that are > currently deployed, would it be sufficient to insert "exec false" > instead of "break"? > > The reason I am asking is *not* to imply that we do not need this > new feature. It

Re: [PATCH v3] coccicheck: process every source file at once

On Tue, Oct 2, 2018 at 1:18 PM Jacob Keller wrote: > > On Tue, Oct 2, 2018 at 1:07 PM Jacob Keller wrote: > > > > From: Jacob Keller > > > > make coccicheck is used in order to apply coccinelle semantic patches, > > and see if any of the transformations foun

Re: [PATCH] coccicheck: process every source file at once

On Wed, Oct 3, 2018 at 8:05 AM SZEDER Gábor wrote: > In fact, it works finer than ever, because running 1.0.0 with this > patch on Travis CI notices a possible memmove() -> MOVE_ARRAY() > conversion: > > https://travis-ci.org/szeder/git/jobs/436542684#L576 > > Surprisingly, running 1.0.0

Re: [PATCH] coccicheck: process every source file at once

On Wed, Oct 3, 2018 at 3:17 AM SZEDER Gábor wrote: > > On Tue, Oct 02, 2018 at 03:55:19PM -0400, Jeff King wrote: > > On Tue, Oct 02, 2018 at 12:16:42PM -0700, Jacob Keller wrote: > > > > > make coccicheck is used in order to apply coccinelle semantic pa

Re: [PATCH] more oideq/hasheq conversions

On Tue, Oct 2, 2018 at 2:19 PM Jeff King wrote: > > We added faster equality-comparison functions for hashes in > 14438c4497 (introduce hasheq() and oideq(), 2018-08-28). A > few topics were in-flight at the time, and can now be > converted. This covers all spots found by "make coccicheck" > in

Re: [PATCH] coccicheck: process every source file at once

On Tue, Oct 2, 2018 at 1:31 PM Jeff King wrote: > Actually, I guess we do not need to save $? at all, since we have only a > single process to care about. So even simpler: > > spatch ... 2>$@+ 2>$@.log || > { > cat $@.log > exit 1 > } > # if we get here, we were successful

Re: [PATCH v3] coccicheck: process every source file at once

On Tue, Oct 2, 2018 at 1:07 PM Jacob Keller wrote: > > From: Jacob Keller > > make coccicheck is used in order to apply coccinelle semantic patches, > and see if any of the transformations found within contrib/coccinelle/ > can be applied to the current code base. > > Pas

[PATCH v3] coccicheck: process every source file at once

From: Jacob Keller make coccicheck is used in order to apply coccinelle semantic patches, and see if any of the transformations found within contrib/coccinelle/ can be applied to the current code base. Pass every file to a single invocation of spatch, instead of running spatch once per source

Re: [PATCH v2] coccicheck: process every source file at once

On Tue, Oct 2, 2018 at 1:03 PM Jacob Keller wrote: > > From: Jacob Keller > > make coccicheck is used in order to apply coccinelle semantic patches, > and see if any of the transformations found within contrib/coccinelle/ > can be applied to the current code base. > > Pas

[PATCH v2] coccicheck: process every source file at once

From: Jacob Keller make coccicheck is used in order to apply coccinelle semantic patches, and see if any of the transformations found within contrib/coccinelle/ can be applied to the current code base. Pass every file to a single invocation of spatch, instead of running spatch once per source

Re: [PATCH] coccicheck: process every source file at once

On Tue, Oct 2, 2018 at 12:55 PM Jeff King wrote: > > On Tue, Oct 02, 2018 at 12:16:42PM -0700, Jacob Keller wrote: > > > make coccicheck is used in order to apply coccinelle semantic patches, > > and see if any of the transformations found within contrib/coccinell

[PATCH] coccicheck: process every source file at once

From: Jacob Keller make coccicheck is used in order to apply coccinelle semantic patches, and see if any of the transformations found within contrib/coccinelle/ can be applied to the current code base. Pass every file to a single invocation of spatch, instead of running spatch once per source

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

On Mon, Sep 17, 2018 at 12:26 PM Junio C Hamano wrote: > FWIW, I didn't mean to say that we should give users a way to > recover. Your "commit -a" or "commit $path" protection just > prevents the situation from happening, and I think it is sufficient. > > The sole point I wanted to raise by

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

On Mon, Sep 17, 2018 at 11:15 AM Jeff King wrote: > > On Mon, Sep 17, 2018 at 07:29:26PM +0200, Duy Nguyen wrote: > > > > On the other hand, if I am keeping some change that should never be > > > in a commit in the working tree file, and building the contents in > > > the index using "add -p" to

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

On Mon, Sep 17, 2018 at 10:09 AM Junio C Hamano wrote: > > It usually is safer (simply because you do not have to think about > it) to start a behaviour change like this as a strict opt-in to gain > confidence. I tend to agree, however.. in this case it could be considered safer to err on the

Re: [PATCH/RFC] commit: new option to abort -a something is already staged

On Fri, Aug 24, 2018 at 7:42 AM Duy Nguyen wrote: > > On Fri, Aug 24, 2018 at 5:02 AM Jacob Keller wrote: > > > > On Thu, Aug 23, 2018 at 9:28 AM Junio C Hamano wrote: > > > I think the above example forgets "-a" on the final "git commit" > >

Re: [PATCH/RFC] commit: new option to abort -a something is already staged

On Thu, Aug 23, 2018 at 9:28 AM Junio C Hamano wrote: > I think the above example forgets "-a" on the final "git commit" > step. With it added, I can understand the concern (and I am sure > you would, too). > > The user is trying to add everything done in the working tree, and > "commit -a"

Re: [PATCH/RFC] commit: new option to abort -a something is already staged

On Mon, Aug 20, 2018 at 8:43 AM Nguyễn Thái Ngọc Duy wrote: > Instead, let's handle just this problem for now. This new option > commit.preciousDirtyIndex, if set to false, will not allow `commit -a` > to continue if the final index is different from the existing one. I > don't think this can be

Re: [ANNOUNCE] Git v2.19.0-rc0

On Thu, Aug 23, 2018 at 5:16 PM Jeff King wrote: > > On Thu, Aug 23, 2018 at 08:06:37PM -0400, Jeff King wrote: > > > This almost works: > > > > @@ > > expression a, b; > > statement s; > > @@ > > - if (oidcmp(a, b)) s > > + if (!oideq(a, b)) s > > > > [...] > > > So I really do want

Re: [ANNOUNCE] Git v2.19.0-rc0

On Thu, Aug 23, 2018 at 9:30 AM Jeff King wrote: > I think that audit isn't actually too bad (but definitely not something > we should do for v2.19). The cocci patch I showed earlier hits most of > them. It misses the negated ones (e.g., "if (oidcmp(...))"). I'm not > sure if there's a way to ask

Re: [PATCH 01/17] cache: update object ID functions for the_hash_algo

On Sun, Jul 8, 2018 at 9:05 PM Eric Sunshine wrote: > > On Sun, Jul 8, 2018 at 10:38 PM Jacob Keller wrote: > > On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson > > wrote: > > > static inline int oidcmp(const struct object_id *oid1, const st

Re: [PATCH 00/17] object_id part 14

On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson wrote: > > This is the fourteenth series of patches to switch to using struct > object_id and the_hash_algo. This series converts several core pieces > to use struct object_id, including the oid* and hex functions. > > All of these patches have

Re: [PATCH 01/17] cache: update object ID functions for the_hash_algo

On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson wrote: > static inline int oidcmp(const struct object_id *oid1, const struct > object_id *oid2) > { > - return hashcmp(oid1->hash, oid2->hash); > + return memcmp(oid1->hash, oid2->hash, the_hash_algo->rawsz); > } > Just curious,

Re: [PATCH 0/8] Reroll of sb/diff-color-move-more

On Thu, May 17, 2018 at 12:46 PM, Stefan Beller wrote: >>> * sb/diff-color-move-more (2018-04-25) 7 commits >>... >>> >>> Will merge to 'next'. >> >>I did not get around to fix it up, there are still review >>comments outstanding. (The test is broken in the last commit.) > > This is a reroll of

Re: [PATCH] add -p: fix counting empty context lines in edited patches

On Fri, Jun 1, 2018 at 10:46 AM, Phillip Wood wrote: > From: Phillip Wood > > recount_edited_hunk() introduced in commit 2b8ea7f3c7 ("add -p: > calculate offset delta for edited patches", 2018-03-05) required all > context lines to start with a space, empty lines are not counted. This > was

Re: commit-graph: change in "best" merge-base when ambiguous

On Mon, May 21, 2018 at 2:54 PM, Jeff King wrote: > Yes, I think this is clearly a case where all of the single merge-bases > we could show are equally good. And I don't think we should promise to > show a particular one, but I _do_ think it's friendly for us to have >

Re: [PATCH v4 3/4] string-list: provide `string_list_appendf()`

On Sun, May 20, 2018 at 3:17 AM, Martin Ågren wrote: > +/** > + * Add formatted string to the end of `list`. This function ignores > + * the value of `list->strdup_strings` and always appends a freshly > + * allocated string, so you will probably not want to use it with >

Re: Add option to git to ignore binary files unless force added

On Fri, May 18, 2018 at 4:31 AM, Anmol Sethi wrote: > This definitely works but it would be more clean to just have git ignore the > binary files from the get go. > Sure it'd be more convenient for you. But there are loads of possible combinations, and the idea of what

Re: [PATCH v2 1/3] merge: setup `opts` later in `checkout_fast_forward()`

On Thu, May 17, 2018 at 2:48 PM, Junio C Hamano wrote: > Martin Ågren writes: > >> After we initialize the various fields in `opts` but before we actually >> use them, we might return early. Move the initialization further down, >> to immediately before

Re: Add option to git to ignore binary files unless force added

On Wed, May 16, 2018 at 5:45 PM, Anmol Sethi wrote: > I think it’d be great to have an option to have git ignore binary files. My > repositories are always source only, committing a binary is always a mistake. > At the moment, I have to configure the .gitignore to ignore every

Re: [PATCH v2 1/3] merge: setup `opts` later in `checkout_fast_forward()`

On Wed, May 16, 2018 at 12:29 PM, Martin Ågren wrote: > On 16 May 2018 at 18:41, Stefan Beller wrote: >> On Wed, May 16, 2018 at 9:30 AM, Martin Ågren wrote: >>> >>> This patch is best viewed using something like this (note the

Re: [PATCH v2 1/3] merge: setup `opts` later in `checkout_fast_forward()`

On Wed, May 16, 2018 at 9:41 AM, Stefan Beller wrote: > + Jonathan Tan for a side discussion on anchoring. > > On Wed, May 16, 2018 at 9:30 AM, Martin Ågren wrote: >> >> This patch is best viewed using something like this (note the tab!): >>

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On Sat, May 5, 2018 at 6:05 PM, Igor Djordjevic wrote: > Hi Dscho, > > On 05/05/2018 23:57, Johannes Schindelin wrote: >> >> > > This builtin does not do a whole lot so far, apart from showing a >> > > usage that is oddly similar to that of `git tbdiff`. And for a >>

Re: Fetching tags overwrites existing tags

On Fri, Apr 27, 2018 at 12:13 PM, Bryan Turner wrote: > On Fri, Apr 27, 2018 at 12:08 PM, Wink Saville wrote: >> >> The other change was rather than using >> ""+refs/tags/*:refs/remote-tags/$name/*" >> I've changed it to

Re: [PATCH 00/18] Add `branch-diff`, a `tbdiff` lookalike

On Thu, May 3, 2018 at 11:05 AM, Ævar Arnfjörð Bjarmason wrote: > > On Thu, May 03 2018, Johannes Schindelin wrote: > >> The incredibly useful `git-tbdiff` tool to compare patch series (say, to see >> what changed between two iterations sent to the Git mailing list) is slightly

Re: [PATCH v3 00/12] get_short_oid UI improvements

On Wed, May 2, 2018 at 6:45 AM, Derrick Stolee wrote: > On 5/2/2018 8:42 AM, Derrick Stolee wrote: >> >> On 5/1/2018 2:40 PM, Ævar Arnfjörð Bjarmason wrote: >>> >>> The biggest change in v3 is the no change at all to the code, but a >>> lengthy explanation of why I didn't go for

Re: [RFC PATCH v4 0/3] Optional sub hierarchy for remote tags

On Tue, May 1, 2018 at 4:24 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jacob Keller <jacob.kel...@gmail.com> writes: > >> I also agree, I'd prefer if we aim for the mapping to be something >> which works for all refs in the future, even if such support isn't &

Re: [RFC PATCH v4 0/3] Optional sub hierarchy for remote tags

On Tue, May 1, 2018 at 12:24 PM, Ævar Arnfjörð Bjarmason wrote: > Thanks a lot for working on this, it's great to have something the > direction of getting rid of this discrepancy between the 1=1 mapping for > branches, but the 1=many mapping for tags. My recent patch series and

Re: Branch deletion question / possible bug?

On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S wrote: > Hi, > > I discovered that I was able to delete the feature branch I was in, due to > some fat fingering on my part and case insensitivity. I never realized this > could be done before. A quick google search did

Re: Fetching tags overwrites existing tags

On Fri, Apr 27, 2018 at 12:08 PM, Wink Saville wrote: > On Thu, Apr 26, 2018 at 4:24 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >> >> Hence (1) we should detect and error out when --prefix-tags is used >> with mirror fetch near

Re: git merge banch w/ different submodule revision

On Fri, Apr 27, 2018 at 5:24 PM, Elijah Newren wrote: > I would expect that a different example involving non-linear history > would behave the same, if both sides update the submodule in a fashion > that is just fast-forwarding and one commit contains the other in its >

Re: git merge banch w/ different submodule revision

On Thu, Apr 26, 2018 at 10:56 AM, Stefan Beller wrote: > We often treating a submodule as a file from the superproject, but not always. > And in case of a merge, git seems to be a bit smarter than treating it > as a textfile > with two different lines. Sure, but a submodule

Re: Fetching tags overwrites existing tags

On Tue, Apr 24, 2018 at 5:52 PM, Junio C Hamano wrote: > Wink Saville writes: > >> Ideally I would have liked the tags fetched from gbenchmark to have a prefix >> of gbenchmark/, like the branches have, maybe something like: >> >> $ git fetch --tags

Re: Fetching tags overwrites existing tags

On Tue, Apr 24, 2018 at 12:57 PM, Wink Saville wrote: > If have a repository with a tag "v1.0.0" and I add a remote repository > which also has a tag "v1.0.0" tag is overwritten. > > Google found [1] from 2011 and option 3 is what I'd like to see. Has it been > implemented and I

Re: [PATCH 1/2] merge: setup `opts` later in `checkout_fast_forward()`

On Mon, Apr 23, 2018 at 10:13 PM, Martin Ågren wrote: > After we initialize the various fields in `opts` but before we actually > use them, we might return early. Move the initialization further down, > to immediately before we use `opts`. > > This limits the scope of

Re: Git enhancement request - checkout (clone) set modified dates to commit date

On Sun, Apr 22, 2018 at 5:23 PM, Andrew Wolfe wrote: > Kevin, thanks for your feedback. > > You have a reasonable point, because usually you don't put the outputs of a > build into version control, but the build script checks them for being > current. > > On the other

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

On Fri, Apr 20, 2018 at 1:26 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Jake, > > On Thu, 19 Apr 2018, Jacob Keller wrote: > >> On Wed, Apr 18, 2018 at 9:24 PM, Sergey Organov <sorga...@gmail.com> wrote: >> > Johannes Schinde

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

On Wed, Apr 18, 2018 at 9:24 PM, Sergey Organov wrote: > Johannes Schindelin writes: > >> Hi Phillip, >> >> On Fri, 13 Apr 2018, Phillip Wood wrote: >> >>> On 12/04/18 23:02, Johannes Schindelin wrote: >>> > >>> > [...] >>> > >>> > So: the order of

Re: Optimizing writes to unchanged files during merges?

On Tue, Apr 17, 2018 at 10:27 AM, Lars Schneider <larsxschnei...@gmail.com> wrote: > >> On 16 Apr 2018, at 19:45, Jacob Keller <jacob.kel...@gmail.com> wrote: >> >> On Mon, Apr 16, 2018 at 10:43 AM, Jacob Keller <jacob.kel...@gmail.com> >> wro

Re: man page for "git remote set-url" seems confusing/contradictory

On Tue, Apr 17, 2018 at 8:34 AM, Robert P. J. Day <rpj...@crashcourse.ca> wrote: > On Tue, 17 Apr 2018, Junio C Hamano wrote: > >> Jacob Keller <jacob.kel...@gmail.com> writes: >> >> > Things won't work so well if you set the push url and fetch url to &

Re: man page for "git remote set-url" seems confusing/contradictory

On Mon, Apr 16, 2018 at 4:13 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jacob Keller <jacob.kel...@gmail.com> writes: > >> Things won't work so well if you set the push url and fetch url to >> different repositories. Git assumes that refs updated by "push&qu

Re: Draft of Git Rev News edition 38

sentence in the "Rebasing merges: a jorney to the >>> ultimate solution (Road Clear) (written by Jacob Keller)" article >>> >>> "A few examples were tried, but it was proven that the original >>> concept did not work, as dropped

Re: man page for "git remote set-url" seems confusing/contradictory

On Mon, Apr 16, 2018 at 9:19 AM, Robert P. J. Day wrote: > On Mon, 16 Apr 2018, Andreas Schwab wrote: > >> On Apr 16 2018, "Robert P. J. Day" wrote: >> >> > i don't understand how you can clearly set the fetch and push URLs >> > of a remote

Re: [PATCH] completion: reduce overhead of clearing cached --options

On Sat, Apr 14, 2018 at 6:27 AM, Jakub Narebski wrote: > SZEDER Gábor writes: >> On Fri, Apr 13, 2018 at 11:44 PM, Jakub Narebski wrote: >>> SZEDER Gábor writes: In Bash we can do better: run the 'compgen

Re: "proper" way to deactivate push for a remote?

On Mon, Apr 16, 2018 at 7:03 AM, Robert P. J. Day wrote: > > another feature i've seen for the very first time ... working with > kubernetes so i checked it out of github, and part of the instructions > for that is to make sure you don't accidentally try to push back to >

Re: Optimizing writes to unchanged files during merges?

On Mon, Apr 16, 2018 at 10:43 AM, Jacob Keller <jacob.kel...@gmail.com> wrote: > On Mon, Apr 16, 2018 at 9:07 AM, Lars Schneider > <larsxschnei...@gmail.com> wrote: >> What if Git kept a LRU list that contains file path, content hash, and >> mtime of any file that

Re: Optimizing writes to unchanged files during merges?

On Mon, Apr 16, 2018 at 9:07 AM, Lars Schneider wrote: > >> On 16 Apr 2018, at 04:03, Linus Torvalds >> wrote: >> >> On Sun, Apr 15, 2018 at 6:44 PM, Junio C Hamano wrote: >>> >>> I think Elijah's corrected

Re: Draft of Git Rev News edition 38

about --preserve-merges and compatibility with scripts >> (i.e. should we change or fix it? or should we deprecate it?) >> followed. >> >>Rebasing merges: a jorney to the ultimate solution (Road Clear) >>(written by Jacob Keller) > > What article by Jac

git blame completion add completion?

Hi, I use git blame sometimes to blame against specific revisions, i.e. "git blame -- " and it would be nice if blame could figure out how to complete the or revision reference.. I tried to take a stab at adding support for this, but I couldn't figure out which completion function to use... I

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

On Thu, Apr 12, 2018 at 3:02 PM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Jake, > > On Thu, 12 Apr 2018, Jacob Keller wrote: > >> On Wed, Apr 11, 2018 at 10:42 PM, Sergey Organov <sorga...@gmail.com> wrote: >> > >> > Jacob Kell

Re: [PATCH v6 15/15] rebase -i --rebase-merges: add a section to the man page

On Thu, Apr 12, 2018 at 2:30 AM, Johannes Schindelin wrote: >> I think it would be worthwhile to point out that unlike the other commands >> this will not preserve untracked files. Maybe something like >> "Note that unlike the `pick` or `merge` commands or initial

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

On Wed, Apr 11, 2018 at 10:42 PM, Sergey Organov <sorga...@gmail.com> wrote: > Hi Jacob, > > Jacob Keller <jacob.kel...@gmail.com> writes: >> On Wed, Apr 11, 2018 at 6:13 AM, Sergey Organov <sorga...@gmail.com> wrote: >>> It was rather --recreate-

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

On Wed, Apr 11, 2018 at 6:13 AM, Sergey Organov wrote: > It was rather --recreate-merges just a few weeks ago, and I've seen > nobody actually commented either in favor or against the > --rebase-merges. > > git rebase --rebase-merges > I'm going to jump in here and say that

Re: [PATCH v5 0/2] *** SUBJECT HERE ***

On Thu, Apr 5, 2018 at 10:27 PM, Taylor Blau wrote: > *** BLURB HERE *** > Missing subject and cover letter stuff.. did you submit before you were ready? or did you not mean to include the cover letter? :) -Jake > Taylor Blau (2): > builtin/config.c: treat type specifiers

Re: [PATCH v2 2/4] push: colorize errors

On Thu, Apr 5, 2018 at 3:48 PM, Johannes Schindelin wrote: > From: Ryan Dammrose > > This is an attempt to resolve an issue I experience with people that are > new to Git -- especially colleagues in a team setting -- where they miss > that

Re: Socket activation for GitWeb FastCGI with systemd?

On Tue, Apr 3, 2018 at 11:53 AM, Alex Ivanov wrote: > Hi. > I want to use systemd as fastcgi spawner for gitweb + nginx. > The traffic is low and number of users is limited + traversal bots. For that > reason I've decided to use following mimimal services > > gitweb.socket >

Re: [RFC PATCH 0/7] Moved code detection: ignore space on uniform indentation

On Tue, Apr 3, 2018 at 12:00 PM, Stefan Beller wrote: The fun is in the last patch, which allows white space sensitive languages to trust the move detection, too. Each block that is marked as moved will have the same delta in {in-, de-}dentation. I would

Re: [RFC PATCH 0/7] Moved code detection: ignore space on uniform indentation

On Mon, Apr 2, 2018 at 4:47 PM, Jonathan Tan wrote: > On Mon, 2 Apr 2018 15:48:47 -0700 > Stefan Beller wrote: > >> This is a re-attempt of [1], which allows the moved code detection to >> ignore blanks in various modes. >> >> patches 1-5 are

Re: Draft of Git Rev News edition 37

On Fri, Mar 30, 2018 at 2:02 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi, > > On Mon, 19 Mar 2018, Christian Couder wrote: > >> On Sun, Mar 18, 2018 at 11:41 PM, Jacob Keller <jacob.kel...@gmail.com> >> wrote: >> > >> >

Re: [PATCH] branch -l: print useful info whilst rebasing a non-local branch

recated "-l" option >> [5/5]: branch: make "-l" a synonym for "--list" > > The entire series looks good to me. FWIW, > > Reviewed-by: Eric Sunshine <sunsh...@sunshineco.com> Same to me. Reviewed-by: Jacob Keller <jacob.kel...@gmail.com> Thanks, Jake

Re: Should I try to fix rebase interactive preserve-merges bug

On Sun, Mar 25, 2018 at 10:32 AM, Wink Saville wrote: > There is a "TODO known breakage" in t3404-rebase-interactve.sh: > >not ok 24 - exchange two commits with -p # TODO known breakage > > I'm contemplating trying to fix it. But with --recreate-merges coming > maybe it's

Re: [PATCH] branch -l: print useful info whilst rebasing a non-local branch

On Sat, Mar 24, 2018 at 9:33 PM, Jeff King wrote: > IMHO we should do one of: > > 1. Nothing. ;) > > 2. Complain about "-l" in list mode to help educate users about the > current craziness. > I think we should do this at a minimum. It's easy, and it doesn't break any

Re: query on git submodule (ignore)

On Sat, Mar 24, 2018 at 7:17 PM, prashant Nidgunde wrote: > Hello, > > I am new to this community ,so please ignore if I am asking anything silly. > > Case : > Today when I built my submodule , and did a git status , it shows as modified. > > After reading certain

Re: Draft of Git Rev News edition 37

On Sun, Mar 18, 2018 at 11:21 AM, Christian Couder wrote: > Hi, > > A draft of a new Git Rev News edition is available here: > > > https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-37.md > > Everyone is welcome to contribute in any section

Re: [PATCH 0/2] routines to generate JSON data

On Fri, Mar 16, 2018 at 2:18 PM, Jeff King wrote: > 3. Some other similar format. YAML comes to mind. Last time I looked > (quite a while ago), it seemed insanely complex, but I think you > could implement only a reasonable subset. OTOH, I think the tools >

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

On Thu, Mar 8, 2018 at 3:20 AM, Phillip Wood wrote: > On 07/03/18 07:26, Johannes Schindelin wrote: >> Hi Buga, >> >> On Tue, 6 Mar 2018, Igor Djordjevic wrote: >> >>> On 06/03/2018 19:12, Johannes Schindelin wrote: >> And I guess being consistent is pretty

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

On Fri, Mar 2, 2018 at 4:36 AM, Phillip Wood wrote: > On 02/03/18 11:17, Phillip Wood wrote: >> >> On 02/03/18 01:16, Igor Djordjevic wrote: >>> >>> Hi Sergey, >>> >>> On 01/03/2018 06:39, Sergey Organov wrote: >> (3) ---X1---o---o---o---o---o---X2 >>

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

On Fri, Mar 2, 2018 at 3:17 AM, Phillip Wood wrote: > > It is interesting to think what it means to faithfully rebase a '-s > ours' merge. In your example the rebase does not introduce any new > changes into branch B that it doesn't introduce to branch A. Had it >

Re: The case for two trees in a commit ("How to make rebase less modal")

On Wed, Feb 28, 2018 at 3:30 PM, Stefan Beller wrote: > $ git hash-object --stdin -w -t commit < tree c70b4a33a0089f15eb3b38092832388d75293e86 > parent 105d5b91138ced892765a84e771a061ede8d63b8 > author Stefan Beller 1519859216 -0800 > committer Stefan

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

On Tue, Feb 27, 2018 at 3:40 PM, Igor Djordjevic wrote: > On 27/02/2018 20:59, Igor Djordjevic wrote: >> >> (3) ---X1---o---o---o---o---o---X2 >>|\ |\ >>| A1---A2---A3---U1 | A1'--A2'--A3'--U1' >>| \

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

On Tue, Feb 27, 2018 at 10:14 AM, Junio C Hamano wrote: > Sergey Organov writes: > >> You've already bit this poor thingy to death. Please rather try your >> teeth on the proposed Trivial Merge (TM) method. > > Whatever you do, do *NOT* call any part of

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

On Tue, Feb 27, 2018 at 8:21 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Jake, > > On Mon, 26 Feb 2018, Jacob Keller wrote: > >> On Mon, Feb 26, 2018 at 4:07 PM, Johannes Schindelin >> <johannes.schinde...@gmx.de> wrote: >> > &g

[PATCH] test case highlighting possible strategy to rebase merge

can actually make it work in practice without requiring separate steps. Signed-off-by: Jacob Keller <jacob.kel...@gmail.com> --- t/t7900-rebasing-merge.sh | 178 ++ 1 file changed, 178 insertions(+) create mode 100755 t/t7900-rebasing-merge.sh

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

On Mon, Feb 26, 2018 at 4:07 PM, Johannes Schindelin wrote: > Hi Buga, > > On Tue, 20 Feb 2018, Igor Djordjevic wrote: > >> I`m really interested in this topic, which seems to (try to) address the >> only "bad feeling" I had with rebasing merges - being afraid of

Re: [PATCH v4 00/12] rebase -i: offer to recreate merge commits

On Fri, Feb 23, 2018 at 4:35 AM, Johannes Schindelin wrote: > Changes since v3: > > - fixed a grammar error in "introduce the `merge` command"'s commit message. > > - fixed a couple of resource leaks in safe_append() and do_reset(), pointed > out by Eric Sunshine. >

Re: Git should preserve modification times at least on request

On Tue, Feb 20, 2018 at 2:05 PM, Peter Backes wrote: > Hi Jeff, > > On Tue, Feb 20, 2018 at 04:16:34PM -0500, Jeff King wrote: >> I think there are some references buried somewhere in that wiki, but did >> you look at any of the third-party tools that store file metadata

Re: Is there any way to "interrupt" a rebase?

On Tue, Feb 20, 2018 at 12:56 PM, Jeff King wrote: > On Tue, Feb 20, 2018 at 12:44:51PM +0100, Johannes Schindelin wrote: > >> > It might be even possible to design a new subcommand for the interactive >> > rebase to facilitate a variation of this strategy (possibly even making >>

Re: Fetch-hooks

On Mon, Feb 19, 2018 at 2:50 PM, Leo Gaspard wrote: > On 02/19/2018 10:23 PM, Jeff King wrote: >> [...] >> If you do go this route, please model it after "pre-receive" rather than >> "update". We had "update" originally but found it was too limiting for >> hooks to see only one

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

On Fri, Feb 16, 2018 at 5:08 AM, Sergey Organov wrote: > Hi, > > By accepting the challenges raised in recent discussion of advanced > support for history rebasing and editing in Git, I hopefully figured out > a clean and elegant method of rebasing merges that I think is "The

Re: git-rebase --undo-skip proposal

On Wed, Feb 14, 2018 at 5:50 PM, Psidium Guajava wrote: > 2018-02-14 22:53 GMT-02:00 Johannes Schindelin : >> Now, when is the next possible time you can call `git rebase --undo-skip`? > > What if the scope were reduced from `--undo-skip` to

Re: git-rebase --undo-skip proposal

On Wed, Feb 14, 2018 at 4:53 PM, Johannes Schindelin wrote: > Hi, > > On Wed, 14 Feb 2018, Psidium Guajava wrote: > >> On 2018-02-13 18:42 GMT-02:00 Stefan Beller wrote: >> > On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava

Re: Fetch-hooks

On Sat, Feb 10, 2018 at 4:21 AM, Jeff King wrote: > On Sat, Feb 10, 2018 at 01:37:20AM +0100, Leo Gaspard wrote: > >> > Yeah, tag-following may be a little tricky, because it usually wants to >> > write to refs/tags/. One workaround would be to have your config look >> > like this:

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

On Mon, Feb 12, 2018 at 11:15 PM, Sergey Organov <sorga...@gmail.com> wrote: > Hi Jake, > > Jacob Keller <jacob.kel...@gmail.com> writes: > >> On Mon, Feb 12, 2018 at 12:39 PM, Johannes Schindelin >> <johannes.schinde...@gmx.de> wrote: >>> Hi

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

On Mon, Feb 12, 2018 at 12:39 PM, Johannes Schindelin wrote: > Hi Sergey, > > On Mon, 12 Feb 2018, Sergey Organov wrote: >> > Have a look at https://github.com/git/git/pull/447, especially the >> > latest commit in there which is an early version of the deprecation I

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

On Thu, Feb 8, 2018 at 11:13 PM, Johannes Sixt wrote: > Am 09.02.2018 um 07:11 schrieb Sergey Organov: >> >> Johannes Schindelin writes: >>> >>> Let me explain the scenario which comes up plenty of times in my work >>> with >>> Git for Windows. We have

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

On Tue, Feb 6, 2018 at 10:16 PM, Sergey Organov wrote: > Johannes Schindelin writes: > > [...] > >> +--recreate-merges:: >> + Recreate merge commits instead of flattening the history by replaying >> + merges. Merge conflict resolutions or

Re: [PATCH 2/8] sequencer: introduce the `merge` command

On Wed, Jan 31, 2018 at 5:48 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Jake & Phillip, > > On Mon, 29 Jan 2018, Johannes Schindelin wrote: > >> On Sat, 20 Jan 2018, Jacob Keller wrote: >> >> > On Fri, Jan 19, 2018 at 6:45

  1   2   3   4   5   6   7   8   9   10   >