Re: [PATCH v2] t5551: mark half-auth no-op fetch test as v0-only
On Fri, Mar 22, 2019 at 12:01:39PM -0700, Jonathan Tan wrote: > When using protocol v0, upload-pack over HTTP permits a "half-auth" > configuration in which, at the web server layer, the info/refs path is > not protected by authentication but the git-upload-pack path is, so that > a user can perform fetches that do not download any objects without > authentication, but still needs authentication to download objects. > > But protocol v2 does not support this, because both ref and pack are > obtained from the git-upload-pack path. > > Mark the test verifying this behavior as protocol v0-only, with a > description of what needs to be done to make v2 support this. Thanks, this looks like a fine solution to me. I do not really expect anyone will ever get around to this NEEDSWORK, but we can see. :) -Peff
Re: [PATCH] Make stashing nothing exit 1
On Sat, Mar 23 2019, Keith Smiley wrote:
> In the case there are no files to stash, but the user asked to stash, we
> should exit 1 since the stashing failed.
> ---
> git-stash.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-stash.sh b/git-stash.sh
> index 789ce2f41d4a3..ca362b1a31277 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -318,7 +318,7 @@ push_stash () {
> if no_changes "$@"
> then
> say "$(gettext "No local changes to save")"
> - exit 0
> + exit 1
> fi
>
> git reflog exists $ref_stash ||
Thanks for contributing, some points:
* stash is currently (in the 'next' branch) being rewritten in C. It's
a better move at this point to patch that version, this code is about
to be deleted.
* This is missing a corresponding test, and skimming the stash manpage
we should document how these exit codes are supposed to act.
* Shouldn't we do this consistently across all the other sub-commands?
Trying some of them seems 'push' may be the odd one out, but maybe
I've missed some (and this would/should be covered by
tests). I.e. some single test that does a bunch of ops with no
entries / nothing to stash and asserts exit codes.
Re: [RFC PATCH 2/2] git-p4: support loading changelist descriptions from files
On Fri, 22 Mar 2019 at 19:54, Mazo, Andrey wrote:
>
> Our Perforce server experienced some kind of database corruption a few years
> ago.
> While the file data and revision history are mostly intact,
> some metadata for several changesets got lost.
I think it's not unheard of for P4 databases to end up being corrupt,
as in your case.
It looks like the RCS files get updated, but the database files (i.e.
the metadata) do not, after which you have a bit of a problem.
So I guess this change could be quite useful, but it really needs some
documentation and tests to support it - git-p4 is already complicated
enough!
Your example script should probably use the same magic that the git-p4
script uses to pick the path to Python.
And perhaps come up with a nicer name than "damaged" - as you say, it
could also be used for other purposes.
> For example, inspecting certain changelists produces errors.
> """
> $ p4 describe -s 12345
> Date 2019/02/26 16:46:17:
> Operation: user-describe
> Operation 'user-describe' failed.
> Change 12345 description missing!
> """
>
> While some metadata (like changeset descriptions) is obviously lost,
> most of it can be reconstructed via other commands:
> * `p4 changes -l -t //...@12345,12345` --
>to obtain date+time, author, beginning of changeset description;
> * `p4 files -a //...@12345,12345` --
>to obtain file revisions, file types, file actions;
> * `p4 diff2 -u //...@12344 //...@12345` --
>to get a unified diff of text files in a changeset;
> * `p4 print -o binary.blob@12345 //depot/binary.blob@12345` --
>to get a revision of a binary file.
>
> It might be possible to teach git-p4 to fallback to other methods if `p4
> describe` fails,
> but it's probably too special-cased (really depends on kind and scale of DB
> corruption),
> so some manual intervention is perhaps acceptable.
>
> So, with some manual work, it's possible to reconstruct `p4 -G describe ...`
> output manually.
> In our case, once git-p4 passes `p4 describe` stage,
> it can proceed further just fine.
> Thus, it's tempting to feed resurrected metadata to git-p4 when a normal `p4
> describe` would fail.
>
> This functionality may be useful to cache changelist information,
> or to make some changes to changelist info before feeding it to git-p4.
>
> A new config parameter is introduced to tell git-p4
> to load certain changelist descriptions from files instead of from a server.
> For simplicity, it's one pickled file per changelist.
> ```
> git config --add git-p4.damagedChangelists 12345.pickled
> git config --add git-p4.damagedChangelists 12346.pickled
> ```
>
> The following trivial script may be used to produce pickled `p4 -G
> describe`-compatible output.
> """
> #!/usr/bin/python2
>
> import pickle
> import time
>
> # recovered commits of interest
> changes = [
> {
> 'change': '12345',
> 'status': 'submitted',
> 'code': 'stat',
> 'user': 'username1',
> 'time': str(int(time.mktime(time.strptime('2019/02/28
> 16:00:30', '%Y/%m/%d %H:%M:%S',
> 'client': 'username1_hostname1',
> 'desc': 'A bug is fixed.\nDetails are below:\n',
> 'depotFile0': '//depot/branch1/foo.sh',
> 'action0':'edit',
> 'rev0': '28',
> 'type0': 'xtext',
> 'depotFile1': '//depot/branch1/bar.py',
> 'action1':'edit',
> 'rev1': '43',
> 'type1': 'text',
> 'depotFile2': '//depot/branch1/baz.doc',
> 'action2':'edit',
> 'rev2': '8',
> 'type2': 'binary',
> 'depotFile3': '//depot/branch1/qqq.c',
> 'action3':'edit',
> 'rev3': '6',
> 'type3': 'ktext',
> },
> ]
>
> for change in changes:
> pickle.dump(change, open('{0}.pickled'.format(change['change']), 'wb'))
> """
>
> Signed-off-by: Andrey Mazo
> ---
>
> Notes:
> Documentation changes and tests are obviously missing,
> but I hoped to get some feedback on the idea overall
> before working on those.
>
> git-p4.py | 25 -
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/git-p4.py b/git-p4.py
> index 40bc84573b..3133419280 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -24,10 +24,11 @@
> import stat
> import zipfile
> import zlib
> import ctypes
> import errno
> +import pickle
>
> # support basestring in python3
> try:
> unicode = unicode
> except NameError:
> @@ -2615,10 +2616,12 @@ def __init__(self):
> self.knownAlienLabelBranches = {}
>
> self.tz = "%+03d%02d" % (- time.timezone / 3600, ((- time.timezone %
> 3600) / 60))
> self.labels = {}
>
> +self.damagedChangelists = {}
> +
> # Force a checkpoint in fast-import and wait for it to finish
> def checkpoint(self):
> self.gitStream.write("checkpoint\n\n")
> self.gitStream
Re: [BUG] Cloning with git HEAD fails for some repositories
On Fri, Mar 22, 2019 at 04:50:34PM +, Eric Wong wrote: > > Weird. I had set http.maxrequests to "1" to give more readable output > > from GIT_CURL_VERBOSE, etc. It fails with that setting, but not with the > > default of 5. Which certainly seems like a bug, but one that has been > > there for a while (at least since v2.9.x, which I tested). > > I couldn't reproduce an error after porting your patch to > master (commit 041f5ea1cf987a40 "The third batch"): > https://80x24.org/spew/20190322163449.25362-...@80x24.org/raw > > So you might've hit an ephemeral error (bad connection, > HTTP server restarting, etc). No, it was quite reproducible. Curious, I decided to bisect. The problem started in ad75ebe5b3 (http: maintain curl sessions, 2009-11-27), but was later fixed by your 2abc848d54 (http: always remove curl easy from curlm session on release, 2016-09-13). So trying to build the fix directly on 17966c0a63d (which is in between those) will run into this unrelated bug. But forward-porting does work. -Peff
Re: [RFC PATCH 1/2] git-p4: introduce alien branch mappings
On Fri, 22 Mar 2019 at 19:54, Mazo, Andrey wrote: > > Labels in Perforce are not global, but can be placed on a particular > view/subdirectory. > This might pose difficulties when importing only parts of Perforce depot into > a git repository. > For example: > 1. Depot layout is as follows: > //depot/metaproject/branch1/subprojectA/... > //depot/metaproject/branch1/subprojectB/... > //depot/metaproject/branch2/subprojectA/... > //depot/metaproject/branch2/subprojectB/... > 2. Labels are placed as follows: > * label 1A on //depot/metaproject/branch1/subprojectA/... > * label 1B on //depot/metaproject/branch1/subprojectB/... > * label 2A on //depot/metaproject/branch2/subprojectA/... > * label 2B on //depot/metaproject/branch2/subprojectB/... > 3. The goal is to import > subprojectA into subprojectA.git and > subprojectB into subprojectB.git > preserving all the branches and labels. > 4. Importing subprojectA. > Label 1A is imported fine because it's placed on certain commit on > branch1. > However, label 1B is not imported because it's placed on a commit in > another subproject: > git-p4 says: "importing label 1B: could not find git commit for > changelist ..." > The same is with label 2A, which is imported; and 2B, which is not. > > Currently, there is no easy way (that I'm aware of) to tell git-p4 to > import an empty commit into a desired branch, > so that a label placed on that changelist could be imported as well, So there is a file in subprojectA/foo.c@41. And label 1B is against //depot/metaproject/branch1/subprojectB/bar.c@42. And I suppose in Perforce you could still checkout subprojectA at change 42 and you would get change 41. But with the way git-p4 works, the label just gets discarded. You want to be able to checkout the subjectA with a tag called 1B and get the file contents as of 42. I wonder if it would be easier to teach the code in importP4Labels to go searching harder for the next lower changelist number? Where it currently says "could not find git commit"... could it do something like "p4 changes -m1 //depot/path/...@LABEL" and use that instead? I'm not sure if that would work but it would mean you wouldn't need any extra configuration to maintain. But perhaps I have misunderstood what you're trying to do here! Perhaps a failing test case might help explain it better? Thanks Luke > It might be possible to get a similar effect by importing both subprojectA > and B in a single git repo, > and then running `git filter-branch --subdirectory-filter subprojectA`, > but this might produce way more irrelevant empty commits, than needed for > labels. > (although imported changelists can be limited with git-p4 --changesfile > option) > > So, introduce a concept of an "alien" branch. > > In the above example of importing subprojectA, > * branch1/subprojectB is an alien branch for branch1/subprojectA; > * branch2/subprojectB is an alien branch for branch2/subprojectA. > Any changelist for branch1/subprojectB will be imported into subprojectA.git > branch1 > as an empty commit for the sole purpose of being labeled with a tag later > or just to preserve the history of changes across the branches. > > This relation between branches is specified in a similar way to branchList: > `git config --add git-p4.alienLabelBranchMap alien_branch:real_branch` > > For the example of importing subprojectA above, config parameters are > ``` > git config --add git-p4.branchList branch1/subprojectA:branch2/subprojectA > git config --add git-p4.alienLabelBranchMap > branch1/subprojectB:branch1/subprojectA > git config --add git-p4.alienLabelBranchMap > branch2/subprojectB:branch2/subprojectA > ``` > > A similar use case, is when a label is placed on a changelist for an excluded > path. > 1. Depot layout is as follows: > //depot/branch1/... > //depot/branch1/exclude_me/... > 2. Labels are placed as follows: > * label 1 on //depot/branch1/... > * label 1E on //depot/branch1/exclude_me/... > 3. The goal is to import > //depot/... into depot.git excluding files under > //depot/branch1/exclude_me/... > and preserving all the branches and labels. > 4. Importing subprojectA. > Label 1 is imported fine because it's placed on certain commit on branch1. > However, label 1E is not imported because it's placed on a commit which > is excluded. > > For this use case, the config would be > ``` > git config --add git-p4.alienLabelBranchMap branch1/exclude_me:branch1 > ``` > > Note that the current implementation doesn't process alien branches > when a clientspec is used. > > Diff best viewed with --ignore-all-space . > > Signed-off-by: Andrey Mazo > --- > > Notes: > Documentation changes and tests are obviously missing, > but I hoped to get some feedback on the idea overall > before working on those. > > A better name for "alien" branches is very welcome. > > git-p4.py | 59 +
Re: [PATCH v2 2/7] git-p4: match branches case insensitively if configured
On Thu, 21 Mar 2019 at 22:32, Mazo, Andrey wrote: > > git-p4 knows how to handle case insensitivity in file paths > if core.ignorecase is set. > However, when determining a branch for a file, > it still does a case-sensitive prefix match. > This may result in some file changes to be lost on import. > > For example, given the following commits > 1. add //depot/main/file1 > 2. add //depot/DirA/file2 > 3. add //depot/dira/file3 > 4. add //depot/DirA/file4 > and "branchList = main:DirA" branch mapping, > commit 3 will be lost. > > So, do branch search case insensitively if running with core.ignorecase set. > Teach splitFilesIntoBranches() to use the p4PathStartsWith() function > for path prefix matches instead of always case-sensitive match. I wonder what other code paths break due to this problem! Looks reasonable but I fear there may be some other holes in there - quickly looking through the code suggests there are several other places this problem occurs. Luke > > Signed-off-by: Andrey Mazo > --- > git-p4.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/git-p4.py b/git-p4.py > index c0a3068b6f..91c610f960 100755 > --- a/git-p4.py > +++ b/git-p4.py > @@ -2721,11 +2721,11 @@ def splitFilesIntoBranches(self, commit): > relPath = self.stripRepoPath(path, self.depotPaths) > > for branch in self.knownBranches.keys(): > # add a trailing slash so that a commit into qt/4.2foo > # doesn't end up in qt/4.2, e.g. > -if relPath.startswith(branch + "/"): > +if p4PathStartsWith(relPath, branch + "/"): > if branch not in branches: > branches[branch] = [] > branches[branch].append(file) > break > > -- > 2.19.2 >
Re: Semantic errors
Il giorno ven, 22/03/2019 alle 18.43 -0400, Randall S. Becker ha scritto: > > -Original Message- > > From: Fabio Aiuto > > Sent: March 22, 2019 17:41 > > To: Randall S. Becker ; git@vger.kernel.org > > Subject: Re: Semantic errors > > > > Il giorno ven, 22/03/2019 alle 17.39 -0400, Randall S. Becker ha > > scritto: > > > On March 22, 2019 17:25, Fabio Aiuto > > > > Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker > > > > ha > > > > scritto: > > > > > > Of On March 21, 2019 15:32, Fabio Aiuto wrote: > > > > > > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. > > > > > > Becker ha > > > > > > scritto: > > > > > > > On March 21, 2019 15:06, Fabio Aiuto wrote: > > > > > > > > I'm browsins git code with Eclipse. I'm on a local > > > > > > > > branch > > > > > > > > called "studio" based on master (last public commit > > > > > > > > e902e9b > > > > > > > > by Junio C Hamano on Monday March 11 2019). I've built > > > > > > > > everything by > > > > > > > > changing: > > > > > > > > CFLAGS = -g -Wall (removing -O2 to have smooth trace in > > > > > > > > debugging). > > > > > > > > But the environment detects the following semantic > > > > > > > > errors (I > > > > > > > > made no > > > > > > > > edits!!!): > > > > > > > > Description ResourcePathLocation > > > > > > > > Type > > > > > > > > Symbol 'GIT_HTML_PATH' could not be resolvedgit > > > > > > > > .c > > > > > > > > /g > > > > > > > > it > > > > > > > > line 154Semantic Error > > > > > > > > Symbol 'GIT_MAN_PATH' could not be resolved git. > > > > > > > > c > > > > > > > > /gi > > > > > > > > t > > > > > > > > line 158Semantic Error > > > > > > > > Symbol 'GIT_INFO_PATH' could not be resolvedgit > > > > > > > > .c > > > > > > > > /g > > > > > > > > it > > > > > > > > line 162Semantic Error > > > > > > > > Symbol 'active_cache' could not be resolved comm > > > > > > > > it.c > > > > > > > > /git > > > > > > > > /builtinline 899Semantic Error > > > > > > > > Field 'ce_intent_to_add(active_cache[i])' could not be > > > > > > > > resolved > > > > > > > > commit.c/git/builtinline 899Sem > > > > > > > > anti > > > > > > > > c > > > > > > > > Error > > > > > > > > Symbol 'active_nr' could not be resolvedcommit. > > > > > > > > c > > > > > > > > /gi > > > > > > > > t/bu > > > > > > > > iltin line 889Semantic Error > > > > > > > > Symbol 'active_nr' could not be resolvedcommit. > > > > > > > > c > > > > > > > > /gi > > > > > > > > t/bu > > > > > > > > iltin line 898Semantic Error > > > > > > > > Field 'oid' could not be resolved commit.c > > > > > > > > /g > > > > > > > > it/b > > > > > > > > uilt > > > > > > > > in > > > > > > > > line 1654 Semantic Error > > > > > > > > Symbol 'active_nr' could not be resolvedcommit. > > > > > > > > c > > > > > > > > /gi > > > > > > > > t/bu > > > > > > > > iltin line 901Semantic Error > > > > > > > > Symbol 'active_cache_tree' could not be resolved > > > > > > > > com > > > > > > > > mit. > > > > > > > > c > > > > > > > > /git/builtinline 1654 Semantic Error > > > > > > > > Symbol 'active_cache_changed' could not be resolved > > > > > > > > comm > > > > > > > > it.c > > > > > > > > /git/builtinline 418Semantic Error > > > > > > > > Symbol 'active_cache_tree' could not be resolved > > > > > > > > com > > > > > > > > mit. > > > > > > > > c > > > > > > > > /git/builtinline 419Semantic Error > > > > > > > > Symbol 'active_nr' could not be resolvedcommit. > > > > > > > > c > > > > > > > > /gi > > > > > > > > t/bu > > > > > > > > iltin line 254Semantic Error > > > > > > > > Symbol 'active_cache' could not be resolved comm > > > > > > > > it.c > > > > > > > > /git > > > > > > > > /builtinline 255Semantic Error > > > > > > > > > > > > > > > > I can debug without problems, but what if I should > > > > > > > > trece > > > > > > > > through one of those errors? > > > > > > > > How can I fix them? > > > > > > > > > > > > > > This situation occurs in many projects in ECLIPSE, not > > > > > > > only > > > > > > > git. > > > > > > > The > > > > > > > errors are likely coming from one of the error parsers > > > > > > > that > > > > > > > you have enabled in your workspace. Look in the Project > > > > > > > Properties or Workspace Preferences under C/C++ > > > > > > > Build/Settings > > > > > > > in the Error Parsers tab for your build configuration. > > > > > > > You may > > > > > > > have to turn off some of those. > > > > > > > There is also the C/C++ General/Code Analysis Preferences > > > > > > > setting where you might have to turn off the problematic > > > > > > > errors. I have found that this is a common situation for > > > > > > > code > > > > > > > that is imported into ECLIPSE from other platforms, where > > > > > > > the > > > > > > > GNU error and analy
Re: Semantic errors
Il giorno ven, 22/03/2019 alle 18.43 -0400, Randall S. Becker ha scritto: > > -Original Message- > > From: Fabio Aiuto > > Sent: March 22, 2019 17:41 > > To: Randall S. Becker ; git@vger.kernel.org > > Subject: Re: Semantic errors > > > > Il giorno ven, 22/03/2019 alle 17.39 -0400, Randall S. Becker ha > > scritto: > > > On March 22, 2019 17:25, Fabio Aiuto > > > > Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker > > > > ha > > > > scritto: > > > > > > Of On March 21, 2019 15:32, Fabio Aiuto wrote: > > > > > > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. > > > > > > Becker ha > > > > > > scritto: > > > > > > > On March 21, 2019 15:06, Fabio Aiuto wrote: > > > > > > > > I'm browsins git code with Eclipse. I'm on a local > > > > > > > > branch > > > > > > > > called "studio" based on master (last public commit > > > > > > > > e902e9b > > > > > > > > by Junio C Hamano on Monday March 11 2019). I've built > > > > > > > > everything by > > > > > > > > changing: > > > > > > > > CFLAGS = -g -Wall (removing -O2 to have smooth trace in > > > > > > > > debugging). > > > > > > > > But the environment detects the following semantic > > > > > > > > errors (I > > > > > > > > made no > > > > > > > > edits!!!): > > > > > > > > Description ResourcePathLocation > > > > > > > > Type > > > > > > > > Symbol 'GIT_HTML_PATH' could not be resolvedgit > > > > > > > > .c > > > > > > > > /g > > > > > > > > it > > > > > > > > line 154Semantic Error > > > > > > > > Symbol 'GIT_MAN_PATH' could not be resolved git. > > > > > > > > c > > > > > > > > /gi > > > > > > > > t > > > > > > > > line 158Semantic Error > > > > > > > > Symbol 'GIT_INFO_PATH' could not be resolvedgit > > > > > > > > .c > > > > > > > > /g > > > > > > > > it > > > > > > > > line 162Semantic Error > > > > > > > > Symbol 'active_cache' could not be resolved comm > > > > > > > > it.c > > > > > > > > /git > > > > > > > > /builtinline 899Semantic Error > > > > > > > > Field 'ce_intent_to_add(active_cache[i])' could not be > > > > > > > > resolved > > > > > > > > commit.c/git/builtinline 899Sem > > > > > > > > anti > > > > > > > > c > > > > > > > > Error > > > > > > > > Symbol 'active_nr' could not be resolvedcommit. > > > > > > > > c > > > > > > > > /gi > > > > > > > > t/bu > > > > > > > > iltin line 889Semantic Error > > > > > > > > Symbol 'active_nr' could not be resolvedcommit. > > > > > > > > c > > > > > > > > /gi > > > > > > > > t/bu > > > > > > > > iltin line 898Semantic Error > > > > > > > > Field 'oid' could not be resolved commit.c > > > > > > > > /g > > > > > > > > it/b > > > > > > > > uilt > > > > > > > > in > > > > > > > > line 1654 Semantic Error > > > > > > > > Symbol 'active_nr' could not be resolvedcommit. > > > > > > > > c > > > > > > > > /gi > > > > > > > > t/bu > > > > > > > > iltin line 901Semantic Error > > > > > > > > Symbol 'active_cache_tree' could not be resolved > > > > > > > > com > > > > > > > > mit. > > > > > > > > c > > > > > > > > /git/builtinline 1654 Semantic Error > > > > > > > > Symbol 'active_cache_changed' could not be resolved > > > > > > > > comm > > > > > > > > it.c > > > > > > > > /git/builtinline 418Semantic Error > > > > > > > > Symbol 'active_cache_tree' could not be resolved > > > > > > > > com > > > > > > > > mit. > > > > > > > > c > > > > > > > > /git/builtinline 419Semantic Error > > > > > > > > Symbol 'active_nr' could not be resolvedcommit. > > > > > > > > c > > > > > > > > /gi > > > > > > > > t/bu > > > > > > > > iltin line 254Semantic Error > > > > > > > > Symbol 'active_cache' could not be resolved comm > > > > > > > > it.c > > > > > > > > /git > > > > > > > > /builtinline 255Semantic Error > > > > > > > > > > > > > > > > I can debug without problems, but what if I should > > > > > > > > trece > > > > > > > > through one of those errors? > > > > > > > > How can I fix them? > > > > > > > > > > > > > > This situation occurs in many projects in ECLIPSE, not > > > > > > > only > > > > > > > git. > > > > > > > The > > > > > > > errors are likely coming from one of the error parsers > > > > > > > that > > > > > > > you have enabled in your workspace. Look in the Project > > > > > > > Properties or Workspace Preferences under C/C++ > > > > > > > Build/Settings > > > > > > > in the Error Parsers tab for your build configuration. > > > > > > > You may > > > > > > > have to turn off some of those. > > > > > > > There is also the C/C++ General/Code Analysis Preferences > > > > > > > setting where you might have to turn off the problematic > > > > > > > errors. I have found that this is a common situation for > > > > > > > code > > > > > > > that is imported into ECLIPSE from other platforms, where > > > > > > > the > > > > > > > GNU error and analy
Compliment of the day to you Dear Friend.
Compliment of the day to you Dear Friend. Dear Friend. I am Mrs.M Compola. am sending this brief letter to solicit your partnership to transfer $5 million US Dollars. I shall send you more information and procedures when I receive positive response from you. Mrs M Compola
[PATCH 1/3] rebase: teach rebase --keep-base
A common scenario is if a user is working on a topic branch and they
wish to make some changes to intermediate commits or autosquashing, they
would run something such as
git rebase -i --onto master... master
in order to preserve the merge base. This prevents unnecessary commit
churning.
Alternatively, a user wishing to test individual commits in a topic
branch without changing anything may run
git rebase -x ./test.sh master... master
Since rebasing onto the merge base of the branch and the upstream is
such a common case, introduce the --keep-base option as a shortcut.
This allows us to rewrite the above as
git rebase -i --keep-base master
and
git rebase -x ./test.sh --keep-base master
respectively.
Signed-off-by: Denton Liu
---
builtin/rebase.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/builtin/rebase.c b/builtin/rebase.c
index 77deebc65c..fffee89064 100644
--- a/builtin/rebase.c
+++ b/builtin/rebase.c
@@ -27,8 +27,8 @@
#include "branch.h"
static char const * const builtin_rebase_usage[] = {
- N_("git rebase [-i] [options] [--exec ] [--onto ] "
- "[] []"),
+ N_("git rebase [-i] [options] [--exec ] "
+ "[--onto | --keep-base] [ []]"),
N_("git rebase [-i] [options] [--exec ] [--onto ] "
"--root []"),
N_("git rebase --continue | --abort | --skip | --edit-todo"),
@@ -1018,6 +1018,7 @@ int cmd_rebase(int argc, const char **argv, const char
*prefix)
};
const char *branch_name;
int ret, flags, total_argc, in_progress = 0;
+ int keep_base = 0;
int ok_to_skip_pre_rebase = 0;
struct strbuf msg = STRBUF_INIT;
struct strbuf revisions = STRBUF_INIT;
@@ -1051,6 +1052,8 @@ int cmd_rebase(int argc, const char **argv, const char
*prefix)
OPT_STRING(0, "onto", &options.onto_name,
N_("revision"),
N_("rebase onto given branch instead of upstream")),
+ OPT_BOOL(0, "keep-base", &keep_base,
+N_("use the merge-base of upstream and branch as the
current base")),
OPT_BOOL(0, "no-verify", &ok_to_skip_pre_rebase,
N_("allow pre-rebase hook to run")),
OPT_NEGBIT('q', "quiet", &options.flags,
@@ -1217,6 +1220,13 @@ int cmd_rebase(int argc, const char **argv, const char
*prefix)
usage_with_options(builtin_rebase_usage,
builtin_rebase_options);
+ if (keep_base) {
+ if (options.onto_name)
+ die(_("cannot combine '--keep-base' with '--onto'"));
+ if (options.root)
+ die(_("cannot combine '--keep-base' with '--root'"));
+ }
+
if (action != NO_ACTION && !in_progress)
die(_("No rebase in progress?"));
setenv(GIT_REFLOG_ACTION_ENVIRONMENT, "rebase", 0);
@@ -1541,10 +1551,19 @@ int cmd_rebase(int argc, const char **argv, const char
*prefix)
}
/* Make sure the branch to rebase onto is valid. */
- if (!options.onto_name)
+ if (keep_base) {
+ strbuf_reset(&buf);
+ strbuf_addstr(&buf, options.upstream_name);
+ strbuf_addstr(&buf, "...");
+ options.onto_name = xstrdup(buf.buf);
+ } else if (!options.onto_name)
options.onto_name = options.upstream_name;
if (strstr(options.onto_name, "...")) {
if (get_oid_mb(options.onto_name, &merge_base) < 0)
+ if (keep_base)
+ die(_("'%s': need exactly one merge base with branch"),
+ options.upstream_name);
+ else
die(_("'%s': need exactly one merge base"),
options.onto_name);
options.onto = lookup_commit_or_die(&merge_base,
--
2.21.0.512.g57bf1b23e1
[PATCH 3/3] git-rebase.txt: document --keep-base option
Document the --keep-base rebase option. While we're at it, change an instance of "merge-base" to "merge base", which is the consistent spelling. Signed-off-by: Denton Liu --- Documentation/git-rebase.txt | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 6363d674b7..780d381667 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -8,8 +8,8 @@ git-rebase - Reapply commits on top of another base tip SYNOPSIS [verse] -'git rebase' [-i | --interactive] [] [--exec ] [--onto ] - [ []] +'git rebase' [-i | --interactive] [] [--exec ] + [--onto | --keep-base] [ []] 'git rebase' [-i | --interactive] [] [--exec ] [--onto ] --root [] 'git rebase' --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch @@ -217,6 +217,12 @@ As a special case, you may use "A\...B" as a shortcut for the merge base of A and B if there is exactly one merge base. You can leave out at most one of A and B, in which case it defaults to HEAD. +--keep-base:: + Set the starting point at which to create the new commits to the + merge base of . Running + 'git rebase --keep-base ' is equivalent to + running 'git rebase --onto ... '. + :: Upstream branch to compare against. May be any valid commit, not just an existing branch name. Defaults to the configured @@ -863,7 +869,7 @@ NOTE: While an "easy case recovery" sometimes appears to be successful --interactive` will be **resurrected**! The idea is to manually tell 'git rebase' "where the old 'subsystem' -ended and your 'topic' began", that is, what the old merge-base +ended and your 'topic' began", that is, what the old merge base between them was. You will have to find a way to name the last commit of the old 'subsystem', for example: -- 2.21.0.512.g57bf1b23e1
[PATCH 0/3] rebase: learn --keep-base
This series teaches rebase the --keep-base option. 'git rebase --keep-base ' is equivalent to 'git rebase --onto ... ' or 'git rebase --onto $(git merge-base HEAD) ' . This seems to be a common case that people (including myself!) run into; I was able to find these StackOverflow posts about this use case: * https://stackoverflow.com/questions/53234798/can-i-rebase-on-a-branchs-fork-point-without-explicitly-specifying-the-parent * https://stackoverflow.com/questions/41529128/how-do-you-rebase-only-changes-between-two-branches-into-another-branch * https://stackoverflow.com/a/4207357 Denton Liu (3): rebase: teach rebase --keep-base t3416: test rebase --keep-base git-rebase.txt: document --keep-base option Documentation/git-rebase.txt | 12 +-- builtin/rebase.c | 25 -- t/t3416-rebase-onto-threedots.sh | 57 3 files changed, 88 insertions(+), 6 deletions(-) -- 2.21.0.512.g57bf1b23e1
[PATCH 2/3] t3416: test rebase --keep-base
Test rebase --keep-base to ensure it works correctly in the normal case and fails when there are multiple merge-bases, both in regular and interactive mode. Also, test to make sure conflicting options causes rebase to fail. While we're at it, add a missing set_fake_editor call to 'rebase -i --onto master...side'. Signed-off-by: Denton Liu --- t/t3416-rebase-onto-threedots.sh | 57 1 file changed, 57 insertions(+) diff --git a/t/t3416-rebase-onto-threedots.sh b/t/t3416-rebase-onto-threedots.sh index ddf2f64853..9c2548423b 100755 --- a/t/t3416-rebase-onto-threedots.sh +++ b/t/t3416-rebase-onto-threedots.sh @@ -99,7 +99,64 @@ test_expect_success 'rebase -i --onto master...side' ' git checkout side && git reset --hard K && + set_fake_editor && test_must_fail git rebase -i --onto master...side J ' +test_expect_success 'rebase --keep-base --onto incompatible' ' + test_must_fail git rebase --keep-base --onto master... +' + +test_expect_success 'rebase --keep-base --root incompatible' ' + test_must_fail git rebase --keep-base --root +' + +test_expect_success 'rebase --keep-base master from topic' ' + git reset --hard && + git checkout topic && + git reset --hard G && + + git rebase --keep-base master && + git rev-parse C >base.expect && + git merge-base master HEAD >base.actual && + test_cmp base.expect base.actual && + + git rev-parse HEAD~2 >actual && + git rev-parse C^0 >expect && + test_cmp expect actual +' + +test_expect_success 'rebase --keep-base master from side' ' + git reset --hard && + git checkout side && + git reset --hard K && + + test_must_fail git rebase --keep-base master +' + +test_expect_success 'rebase -i --keep-base master from topic' ' + git reset --hard && + git checkout topic && + git reset --hard G && + + set_fake_editor && + EXPECT_COUNT=2 git rebase -i --keep-base master && + git rev-parse C >base.expect && + git merge-base master HEAD >base.actual && + test_cmp base.expect base.actual && + + git rev-parse HEAD~2 >actual && + git rev-parse C^0 >expect && + test_cmp expect actual +' + +test_expect_success 'rebase -i --keep-base master from side' ' + git reset --hard && + git checkout side && + git reset --hard K && + + set_fake_editor && + test_must_fail git rebase -i --keep-base master +' + test_done -- 2.21.0.512.g57bf1b23e1
[PATCH] gitk: Do not mistake unchanged lines with submodule changes
Unchanged lines are prefixed with a white-space, thus unchanged lines
starting with either " <" or " >" are mistaken for submodule changes.
Check if a line starts with either " <" or " >" only if we listing
the changes of a submodule.
Signed-off-by: Gabriele Mazzotta
---
gitk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index a14d7a1..dd4bbbf 100755
--- a/gitk
+++ b/gitk
@@ -8191,11 +8191,11 @@ proc parseblobdiffline {ids line} {
} else {
$ctext insert end "$line\n" filesep
}
-} elseif {![string compare -length 3 " >" $line]} {
+} elseif {$currdiffsubmod != "" && ![string compare -length 3 " >"
$line]} {
set $currdiffsubmod ""
set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" dresult
-} elseif {![string compare -length 3 " <" $line]} {
+} elseif {$currdiffsubmod != "" && ![string compare -length 3 " <"
$line]} {
set $currdiffsubmod ""
set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" d0
--
2.20.1
Re: [PATCH] asciidoctor-extensions: provide ``
Hi,
Martin Ågren wrote:
> On Wed, 20 Mar 2019 at 19:17, Todd Zullinger wrote:
>> Martin Ågren wrote:
>>> {litdd} now renders as --. We should find some other way to
>>> produce '--'. This should then be a simple change, as we're already
>>> providing this attribute inside an `ifdef USE_ASCIIDOCTOR`.
>>
>> I noticed that one and didn't work out a good fix, but it
>> sounds like you have one in mind. That's great.
>>
>>> "+" becomes "+". I didn't immediately find where we do that.
>>
>> For this one, I was working on replacing "{plus}" with `+`
>> (along with " " and "-"). That's probably not ideal though.
>
> The "plus" and "litdd" issues seem like they can be solved by doing:
>
> ASCIIDOC_EXTRA += -aplus='+'
> ASCIIDOC_EXTRA += -alitdd='\--'
Hmm, setting litdd makes the html generate an em dash
followed by a zero width space (in 1.5.8 and 2.0.0)
I updated my system to asciidoctor-2.0.0 last night and now
I can't even generate the man pages properly, because the
docbook45 converter was removed. I'll have to see if I
missed some other required update. :/
> It would probably be worthwhile to try 1.5.7+ to see how much that
> improves things. Seems like you're already underway there.
Yeah, before I knew how soon 2.0.0 was coming, I updated to
1.5.8 and built the various Fedora packages which require it
to see how they handled it. Almost all of the changes were
fixes to bugs in previous versions. And the one which was
not is likely to be fixed in 2.0.0 according to asciidoctor
maintainer Dan Allen.
Have you looked at diffing the html output as well? It
seems like we'll need to check it as well to be sure any
fixes to the manpage output don't have a negative impact on
the html output, and vice versa.
I used 'links -dump' output for comparison of the various
Fedora packages which currently build with asciidoctor.
It's not perfect. It could miss visual changes which might
be important when viewed in a graphical browser. But it was
better than trying to diff the html files directly. :)
We probably also want to check the validity of links within
the docs, as one of the changes in 1.5.8 caused breakage of
cross interdocument references. (This is the change I noted
above which should be fixed in 2.0.0.)
It'll be quite a while until most systems with asciidoctor
1.5.x are gone. I doubt that upgrading to even 1.5.8 is
suitable for the currently released Fedora versions due to
incompatible changes. I am going to try and get 2.0.0 into
Fedora 30, but the deadline for changes has just passed, so
I may not be able to do so. If not, it'll be 6-8 months
until a released version of Fedora has an asciidoctor newer
than 1.5.6.1.
All that is just to say that even if newer asciidoctor fixes
many of the issues we've seen it will still be a long time
before we can reasonable default to asciidoctor or drop
asciidoc support.
For what it's worth, the Fedora asciidoc packages moved to
python3 using https://github.com/asciidoc/asciidoc-py3.
That's not very active, but it should at least keep asciidoc
alive beyond the approaching python2 EOL.
--
Todd
RE: Semantic errors
On March 23, 2019 9:00, Fabio Aiuto wrote: > To: Randall S. Becker ; git@vger.kernel.org > Subject: Re: Semantic errors > > Il giorno ven, 22/03/2019 alle 18.43 -0400, Randall S. Becker ha > scritto: > > > -Original Message- > > > From: Fabio Aiuto > > > Sent: March 22, 2019 17:41 > > > To: Randall S. Becker ; git@vger.kernel.org > > > Subject: Re: Semantic errors > > > > > > Il giorno ven, 22/03/2019 alle 17.39 -0400, Randall S. Becker ha > > > scritto: > > > > On March 22, 2019 17:25, Fabio Aiuto > > > > > Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker ha > > > > > scritto: > > > > > > > Of On March 21, 2019 15:32, Fabio Aiuto wrote: > > > > > > > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. > > > > > > > Becker ha > > > > > > > scritto: > > > > > > > > On March 21, 2019 15:06, Fabio Aiuto wrote: > > > > > > > > > I'm browsins git code with Eclipse. I'm on a local > > > > > > > > > branch called "studio" based on master (last public > > > > > > > > > commit e902e9b by Junio C Hamano on Monday March 11 > > > > > > > > > 2019). I've built everything by > > > > > > > > > changing: > > > > > > > > > CFLAGS = -g -Wall (removing -O2 to have smooth trace in > > > > > > > > > debugging). > > > > > > > > > But the environment detects the following semantic > > > > > > > > > errors (I made no > > > > > > > > > edits!!!): > > > > > > > > > Description ResourcePathLocation > > > > > > > > > Type > > > > > > > > > Symbol 'GIT_HTML_PATH' could not be resolved git > > > > > > > > > .c > > > > > > > > > /g > > > > > > > > > it > > > > > > > > > line 154 Semantic Error > > > > > > > > > Symbol 'GIT_MAN_PATH' could not be resolved git. > > > > > > > > > c > > > > > > > > > /gi > > > > > > > > > t > > > > > > > > > line 158 Semantic Error > > > > > > > > > Symbol 'GIT_INFO_PATH' could not be resolved git > > > > > > > > > .c > > > > > > > > > /g > > > > > > > > > it > > > > > > > > > line 162 Semantic Error > > > > > > > > > Symbol 'active_cache' could not be resolved comm > > > > > > > > > it.c > > > > > > > > > /git > > > > > > > > > /builtin line 899Semantic Error > > > > > > > > > Field 'ce_intent_to_add(active_cache[i])' could not be > > > > > > > > > resolved > > > > > > > > > commit.c /git/builtinline 899Sem > > > > > > > > > anti > > > > > > > > > c > > > > > > > > > Error > > > > > > > > > Symbol 'active_nr' could not be resolved commit. > > > > > > > > > c > > > > > > > > > /gi > > > > > > > > > t/bu > > > > > > > > > iltin line 889Semantic Error > > > > > > > > > Symbol 'active_nr' could not be resolved commit. > > > > > > > > > c > > > > > > > > > /gi > > > > > > > > > t/bu > > > > > > > > > iltin line 898Semantic Error > > > > > > > > > Field 'oid' could not be resolved commit.c > > > > > > > > > /g > > > > > > > > > it/b > > > > > > > > > uilt > > > > > > > > > in > > > > > > > > > line 1654 Semantic Error > > > > > > > > > Symbol 'active_nr' could not be resolved commit. > > > > > > > > > c > > > > > > > > > /gi > > > > > > > > > t/bu > > > > > > > > > iltin line 901Semantic Error > > > > > > > > > Symbol 'active_cache_tree' could not be resolved > > > > > > > > > com > > > > > > > > > mit. > > > > > > > > > c > > > > > > > > > /git/builtin line 1654 Semantic Error > > > > > > > > > Symbol 'active_cache_changed' could not be resolved comm > > > > > > > > > it.c > > > > > > > > > /git/builtin line 418Semantic Error > > > > > > > > > Symbol 'active_cache_tree' could not be resolved > > > > > > > > > com > > > > > > > > > mit. > > > > > > > > > c > > > > > > > > > /git/builtin line 419Semantic Error > > > > > > > > > Symbol 'active_nr' could not be resolved commit. > > > > > > > > > c > > > > > > > > > /gi > > > > > > > > > t/bu > > > > > > > > > iltin line 254Semantic Error > > > > > > > > > Symbol 'active_cache' could not be resolved comm > > > > > > > > > it.c > > > > > > > > > /git > > > > > > > > > /builtin line 255Semantic Error > > > > > > > > > > > > > > > > > > I can debug without problems, but what if I should trece > > > > > > > > > through one of those errors? > > > > > > > > > How can I fix them? > > > > > > > > > > > > > > > > This situation occurs in many projects in ECLIPSE, not > > > > > > > > only git. > > > > > > > > The > > > > > > > > errors are likely coming from one of the error parsers > > > > > > > > that you have enabled in your workspace. Look in the > > > > > > > > Project Properties or Workspace Preferences under C/C++ > > > > > > > > Build/Settings in the Error Parsers tab for your build > > > > > > > > configuration. > > > > > > > > You may > > > > > > > > have to turn off some of those. > > > > > > > > There is also the C/C++ General/Code Analysis Preferences > > > > > > > > setting where you might have to turn off the problematic > > > > > > > > errors. I have found that this is a c
Re: [GSoC][RFC/PATCH] userdiff: added support for diffing shell scripts
On Fri, Mar 22, 2019 at 5:08 PM Kapil Jain wrote: > > Signed-off-by: Kapil Jain > --- > > The test written does not pass, imo there's some problem with the regex part. > please let me know about the fault. To save some work by people who could help you, it might be a good idea to show the output of the failing test, for example the output of `./t4034-diff-words.sh -i -v` or `./t4034-diff-words.sh -i -v -x`.
Re: [PATCH v3 1/1] trace2: write to directory targets
On Thu, Mar 21 2019, Josh Steadmon wrote:
> When the value of a trace2 environment variable is an absolute path
> referring to an existing directory, write output to files (one per
> process) underneath the given directory. Files will be named according
> to the final component of the trace2 SID, followed by a counter to avoid
> potential collisions.
Is this "counter to avoid collisions" something you've seen the need to
have in practice, or could we just squash this on top:
diff --git a/trace2/tr2_dst.c b/trace2/tr2_dst.c
index c3d82ca6a4..06cbef5837 100644
--- a/trace2/tr2_dst.c
+++ b/trace2/tr2_dst.c
@@ -13,11 +13,6 @@
*/
#define TR2_ENVVAR_DST_DEBUG "GIT_TR2_DST_DEBUG"
-/*
- * How many attempts we will make at creating an automatically-named trace
file.
- */
-#define MAX_AUTO_ATTEMPTS 10
-
static int tr2_dst_want_warning(void)
{
static int tr2env_dst_debug = -1;
@@ -48,7 +43,6 @@ static int tr2_dst_try_auto_path(struct tr2_dst *dst,
const char *tgt_prefix)
const char *last_slash, *sid = tr2_sid_get();
struct strbuf path = STRBUF_INIT;
size_t base_path_len;
- unsigned attempt_count;
last_slash = strrchr(sid, '/');
if (last_slash)
@@ -60,17 +54,7 @@ static int tr2_dst_try_auto_path(struct tr2_dst *dst,
const char *tgt_prefix)
strbuf_addstr(&path, sid);
base_path_len = path.len;
- for (attempt_count = 0; attempt_count < MAX_AUTO_ATTEMPTS;
attempt_count++) {
- if (attempt_count > 0) {
- strbuf_setlen(&path, base_path_len);
- strbuf_addf(&path, ".%d", attempt_count);
- }
-
- fd = open(path.buf, O_WRONLY | O_CREAT | O_EXCL, 0666);
- if (fd != -1)
- break;
- }
-
+ fd = open(path.buf, O_WRONLY | O_CREAT | O_EXCL, 0666);
if (fd == -1) {
if (tr2_dst_want_warning())
warning("trace2: could not open '%.*s' for '%s'
tracing: %s",
The reason I'm raising this is that it seems like sweeping an existing
issue under the rug. We document that the "sid" is "unique", and it's just:
-
So that might be a lie, and in particular I can imagine that say if
every machine at Google is logging traces into some magic mounted FS
that there'll be collisions there.
But then let's *fix that*, because we're also e.g. going to have other
consumers of these traces using the sid's as primary keys in a logging
system.
I wonder if we should just make it a bit longer, human-readable, and
include a hash of the hostname:
perl -MTime::HiRes=gettimeofday -MSys::Hostname -MDigest::SHA=sha1_hex
-MPOSIX=strftime -wE '
my ($t, $m) = gettimeofday;
my $host_hex = substr sha1_hex(hostname()), 0, 8;
my $htime = strftime("%Y%m%d%H%M%S", localtime);
my $sid = sprintf("%s-%6d-%s-%s",
$htime,
$m,
$host_hex,
$$ & 0x,
);
say $sid;
'
Which gets you a SID like:
20190323213918-404788-c2f5b994-19027
I.e.:
--<8 chars of sha1(hostname -f)>-
There's obviously ways to make that more compact, but in this case I
couldn't see a reason to, also using UTC would be a good idea.
All the trace2 tests pass if I fake that up. Jeff H: Do you have
anything that relies on the current format?
> This makes it more convenient to collect traces for every git invocation
> by unconditionally setting the relevant trace2 envvar to a constant
> directory name.
>
> Signed-off-by: Josh Steadmon
> ---
> Documentation/technical/api-trace2.txt | 5 ++
> t/t0210-trace2-normal.sh | 15 ++
> trace2/tr2_dst.c | 63 +-
> 3 files changed, 81 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/technical/api-trace2.txt
> b/Documentation/technical/api-trace2.txt
> index 2de565fa3d..d0948ba250 100644
> --- a/Documentation/technical/api-trace2.txt
> +++ b/Documentation/technical/api-trace2.txt
> @@ -109,6 +109,11 @@ values are recognized.
>
> Enables the target, opens and writes to the file in append mode.
>
> + If the target already exists and is a directory, the traces will be
> + written to files (one per process) underneath the given directory. They
> + will be named according to the last component of the SID (optionally
> + followed by a counter to avoid filename collisions).
> +
> `af_unix:[:]`::
>
> Enables the target, opens and writes to a Unix Domain Socket
> diff --git a/t/t0210-trace2-normal.sh b/t/t0210-trace2-normal.sh
> index 03a0aedb1d..819430658b 100755
> --- a/t/t0210-trace2-normal.sh
> +++ b/t/t0210-trace2-normal.sh
> @@ -80,6 +80,21 @@ test_expect_success 'normal stream, return code 1' '
> test_cmp expect actual
> '
>
> +test_expect_success 'automatic filename' '
> + test_when_finished "rm -r traces a
Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands
Hi Rohit,
On Fri, Mar 22, 2019 at 4:12 PM Rohit Ashiwal
wrote:
>
> Hey People
>
> I am Rohit Ashiwal and here my first draft of the proposal for the project
> titled: `Improve consistency of sequencer commands' this summer. I need your
> feedback and more than that I need help to improve the timeline of this
> proposal since it looks very weak. Basically, it lacks the "how" component
> as I don't know much about the codebase in detail.
>
> Thanks
> Rohit
>
> PS: Point one is missing in the timeline from the ideas page[0], can someone
> explain what exactly it wants?
You mean this point from the idea page:
"The suggestion to fix an interrupted rebase-i or cherry-pick due to a
commit that became empty via git reset HEAD (in builtin/commit.c)
instead of git rebase --skip or git cherry-pick --skip ranges from
annoying to confusing. (Especially since other interrupted am’s and
rebases both point to am/rebase –skip.). Note that git cherry-pick
--skip is not yet implemented, so that would have to be added first."
or something else?
By the way it is not very clear if the proposal uses markdown or
another related format and if it is also possible (and perhaps even
better visually) to see it somewhere else (maybe on GitHub). If that's
indeed possible, please provide a link. It is a good thing though to
still also send it attached to an email, so that it can be easily
reviewed and commented on by people who prefer email discussions.
> List of Contributions at Git:
> -
> Status: Merge in next revision
Maybe "Merged into the 'next' branch"
> git/git:
> [Micro](3): Use helper functions in test script.
Please give more information than that, for example you could point to
the commit in the next branch on GitHub and perhaps to the what's
cooking email from Junio where it can be seen that the patch has been
merged into next and what's its current status.
> Status: Merged
> git-for-windows/git:
> [#2077](4): [FIX] git-archive error, gzip -cn : command not found.
>
> Status: Merged
> git-for-windows/build-extra:
> [#235](5): installer: Fix version of installer and installed file.
For Git for Windows contributions I think a link to the pull request
is enough. It could be nice to know though if the commits are part of
a released version.
> The Project: `Improve consistency of sequencer commands'
>
>
> Overview
>
> git-sequencer was introduced by Stephan Beyer as his
> GSoC 2008 project[6]. It executed a sequence of git instructions to
> or and the sequence was given by a or through stdin. The
> git-sequencer wants to become the common backend for git-am, git-rebase
> and other git commands. The project was continued by Ramkumar
>
> in 2011[7], converting it to a builtin and extending its domain to
> git-cherry-pick.
Yeah, you can say that it was another GSoC project and maybe give his
full name (Ramkumar Ramachandra).
There have been more related work to extend usage of the sequencer
after these GSoC projects, at least from Dscho and maybe from Alban
Gruin and Elijah too. I would be nice if you could document that a
bit.
> As of now, there are still some inconsistencies among these commands, e.g.,
> there is no `--skip` flag in `git-cherry-pick` while one exists for
> `git-rebase`.
> This project aims to remove inconsistencies in how the command line options
> are
> handled.
> Points to work on:
> --
> - Add `git cherry-pick --skip`
> - Implement flags that am-based rebases support, but not interactive
> or merge based, in interactive/merge based rebases
Maybe the flags could be listed.
> - [Bonus] Deprecate am-based rebases
> - [Bonus] Make a flag to allow rebase to rewrite commit messages that
> refer to older commits that were also rebased
This part of your proposal ("Points to work on") looks weak to me.
Please try to add more details about what you plan to do, how you
would describe the new flags in the documentation, which *.c *.h and
test files might be changed, etc.
> Proposed Timeline
> -
> + Community Bonding (May 6th - May 26th):
> - Introduction to community
> - Get familiar with the workflow
> - Study and understand the workflow and implementation of the project
> in detail
>
> + Phase 1 (May 27th - June 23rd):
> - Start with implementing `git cherry-pick --skip`
> - Write new tests for the just introduced flag(s)
> - Analyse the requirements and differences of am-based and other
> rebases flags
>
> + Phase 2 (June 24th - July 21st):
> - Introduce flags of am-based rebases to other kinds.
> - Add tests for the same.
>
> + Phase 3 (July 22th - August 19th):
> - Act on [Bonus] features
> - Documentation
> - Clean up tasks
>
>
> Relevant Work
> =
> Dscho and I had a talk on how a non-am backend should i
Git excludes fails to avoid git submodule warning
Working with Git 2.21.0 on Linux: The git-add(1) man page says: "The optional configuration variable core.excludesFile indicates a path to a file containing patterns of file names to exclude from git-add" But if I do this: $ echo "docs/themes/*/.git >> .gitexcludes $ git config core.excludeFiles .gitexcludes $ git add docs warning: adding embedded git repository: docs/themes/foo It seems to me that this goes against what the git-add(1) man page says. A workaround I found on stackoverflow is to add any file within the target directory: $ git add docs/themes/foo/README And then add everything: $ git add docs In which case the contents of .gitexcludes is honoured. But that seems like a hack. Am I experiencing the intended result of Git's exclude function? If so, I'll happily submit a patch to the man page to clarify this behaviour. If not, I guess I'm submitting a bug report here. Thanks for all the amazing work. Cheers.
Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands
Hi Rohit!
On Fri, Mar 22, 2019 at 8:12 AM Rohit Ashiwal
wrote:
>
> Hey People
>
> I am Rohit Ashiwal and here my first draft of the proposal for the project
> titled: `Improve consistency of sequencer commands' this summer. I need your
> feedback and more than that I need help to improve the timeline of this
> proposal since it looks very weak. Basically, it lacks the "how" component
> as I don't know much about the codebase in detail.
>
> Thanks
> Rohit
>
> PS: Point one is missing in the timeline from the ideas page[0], can someone
> explain what exactly it wants?
I don't understand the question; could you restate it?
> Points to work on:
> --
> - Add `git cherry-pick --skip`
I'd reword this section as 'Consistently suggest --skip for operations
that have such a concept'.[1]
Adding a --skip flag to cherry-pick is useful, but was only meant as a
step. Let me explain in more detail and use another comparison point.
Each of the git commands cherry-pick, merge, rebase take the flags
"--continue" and "--abort"; but they didn't always do so and so
continuing or aborting an operation often used special case-specific
commands for each (e.g. git reset --hard (or later --merge) to abort a
merge, git commit to continue it, etc.) Those commands don't
necessarily make sense to users, whereas ' --continue' and
' --abort' do make intuitive sense and is thus memorable.
We want the same for --skip.
Both am-based rebases and am itself will give advice to the user to
use 'git rebase --skip' or 'git am --skip' when a patch isn't needed.
That's good. In contrast, interactive-based rebases and cherry-pick
will suggest that the user run 'git reset' (with no arguments). The
place that suggests that command should instead suggest either 'git
rebase --skip' or 'git cherry-pick --skip', depending on which
operation is in progress. The first step for doing that, is making
sure that cherry-pick actually has a '--skip' option.
> - Implement flags that am-based rebases support, but not interactive
> or merge based, in interactive/merge based rebases
The "merge-based" rebase backend was deleted in 2.21.0, with all its
special flags reimplemented on the top of the interactive backend. So
we can omit the deleted backend from the descriptions (instead just
talk about the am-based and interactive backends).
> - [Bonus] Deprecate am-based rebases
> - [Bonus] Make a flag to allow rebase to rewrite commit messages that
> refer to older commits that were also rebased
I'd reorder these two. I suspect the second won't be too hard and
will provide a new user-visible feature, while the former will
hopefully not be visible to users; if the former has more than
cosmetic differences visible to user, it might transform the problem
into more of a social problem than a technical one or just make into
something we can't do.
> Proposed Timeline
> -
> + Community Bonding (May 6th - May 26th):
> - Introduction to community
> - Get familiar with the workflow
> - Study and understand the workflow and implementation of the project
> in detail
>
> + Phase 1 (May 27th - June 23rd):
> - Start with implementing `git cherry-pick --skip`
> - Write new tests for the just introduced flag(s)
> - Analyse the requirements and differences of am-based and other
> rebases flags
Writing or finding tests to trigger all the --skip codepaths might be
the biggest part of this phase. Implementing `git cherry-pick --skip`
just involves making it run the code that `git reset` invokes. The
you change the error message to reference ` --skip` instead
of `git reset`. What you're calling phase 1 here isn't quite
microproject sized, but it should be relatively quick and easy; I'd
plan to spend much more of your time on phase 2.
> + Phase 2 (June 24th - July 21st):
> - Introduce flags of am-based rebases to other kinds.
> - Add tests for the same.
You should probably mention the individual cases from "INCOMPATIBLE
FLAGS" of the git rebase manpage. Also, some advice for order of
tackling these: I think you should probably do --ignore-whitespace
first; my guess is that one is the easiest. Close up would be
--committer-date-is-author-date and --ignore-date. Re-reading, I'm
not sure -C even makes sense at all; it might be that the solution is
just accepting the flag and ignoring it, or perhaps it remains the one
flag the interactive backend won't support, or maybe there is
something that makes sense to be done. There'd need to be a little
investigation for that one, but it might turn out simple too. The
--whitespace={nowarn|warn|fix|error|error-all} flag will be the
kicker. I don't know how long that one will take, but I'm certain
it's harder than the other flags and it might conceivably take up most
the summer or even extend beyond.
> + Phase 3 (July 22th - August 19th):
> - Act on [Bonus] features
Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands
Hi Christian
On 2019-03-23 22:17 UTC Christian Couder <> wrote:
> On Fri, Mar 22, 2019 at 4:12 PM Rohit Ashiwal
> wrote:
> >
> > Hey People
> >
> > I am Rohit Ashiwal and here my first draft of the proposal for the project
> > titled: `Improve consistency of sequencer commands' this summer. I need your
> > feedback and more than that I need help to improve the timeline of this
> > proposal since it looks very weak. Basically, it lacks the "how" component
> > as I don't know much about the codebase in detail.
> >
> > Thanks
> > Rohit
> >
> > PS: Point one is missing in the timeline from the ideas page[0], can someone
> > explain what exactly it wants?
>
> You mean this point from the idea page:
>
> "The suggestion to fix an interrupted rebase-i or cherry-pick due to a
> commit that became empty via git reset HEAD (in builtin/commit.c)
> instead of git rebase --skip or git cherry-pick --skip ranges from
> annoying to confusing. (Especially since other interrupted am’s and
> rebases both point to am/rebase –skip.). Note that git cherry-pick
> --skip is not yet implemented, so that would have to be added first."
Yes.
> or something else?
>
> By the way it is not very clear if the proposal uses markdown or
> another related format and if it is also possible (and perhaps even
> better visually) to see it somewhere else (maybe on GitHub). If that's
> indeed possible, please provide a link. It is a good thing though to
> still also send it attached to an email, so that it can be easily
> reviewed and commented on by people who prefer email discussions.
This was intentional. Here is the link of the proposal hosted at
gist.github.com[1],
those who prefer text only version here[2] is mailing list link.
> > List of Contributions at Git:
> > -
> > Status: Merge in next revision
>
> Maybe "Merged into the 'next' branch"
>
> > git/git:
> > [Micro](3): Use helper functions in test script.
>
> Please give more information than that, for example you could point to
> the commit in the next branch on GitHub and perhaps to the what's
> cooking email from Junio where it can be seen that the patch has been
> merged into next and what's its current status.
Current proposal has added links to those commits.
> > Status: Merged
> > git-for-windows/git:
> > [#2077](4): [FIX] git-archive error, gzip -cn : command not found.
This was released in v2.21.0 [3]
> > Status: Merged
> > git-for-windows/build-extra:
> > [#235](5): installer: Fix version of installer and installed file.
>
> For Git for Windows contributions I think a link to the pull request
> is enough. It could be nice to know though if the commits are part of
> a released version.
> > The Project: `Improve consistency of sequencer commands'
> >
> >
> > Overview
> >
> > git-sequencer was introduced by Stephan Beyer as his
> > GSoC 2008 project[6]. It executed a sequence of git instructions to
> > or and the sequence was given by a or through stdin. The
> > git-sequencer wants to become the common backend for git-am, git-rebase
> > and other git commands. The project was continued by Ramkumar
> >
> > in 2011[7], converting it to a builtin and extending its domain to
> > git-cherry-pick.
>
> Yeah, you can say that it was another GSoC project and maybe give his
> full name (Ramkumar Ramachandra).
>
> There have been more related work to extend usage of the sequencer
> after these GSoC projects, at least from Dscho and maybe from Alban
> Gruin and Elijah too. I would be nice if you could document that a
> bit.
>
> > As of now, there are still some inconsistencies among these commands, e.g.,
> > there is no `--skip` flag in `git-cherry-pick` while one exists for
> > `git-rebase`.
> > This project aims to remove inconsistencies in how the command line options
> > are
> > handled.
>
>
> > Points to work on:
> > --
> > - Add `git cherry-pick --skip`
> > - Implement flags that am-based rebases support, but not interactive
> > or merge based, in interactive/merge based rebases
>
> Maybe the flags could be listed.
>
> > - [Bonus] Deprecate am-based rebases
> > - [Bonus] Make a flag to allow rebase to rewrite commit messages that
> > refer to older commits that were also rebased
>
> This part of your proposal ("Points to work on") looks weak to me.
>
> Please try to add more details about what you plan to do, how you
> would describe the new flags in the documentation, which *.c *.h and
> test files might be changed, etc.
I'll soon add details to the proposal, currently digging deep into the mailing
list.
> > Proposed Timeline
> > -
> > + Community Bonding (May 6th - May 26th):
> > - Introduction to community
> > - Get familiar with the workflow
> > - Study and understand the workflow and implementation of the
> > project in detail
> >
> > + Phase 1 (
Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands
Hi Elijah!
On Sat, 23 Mar 2019 18:07:17 -0700 Elijah Newren wrote:
> Hi Rohit!
>
> On Fri, Mar 22, 2019 at 8:12 AM Rohit Ashiwal
> wrote:
> > PS: Point one is missing in the timeline from the ideas page[0], can someone
> > explain what exactly it wants?
>
> I don't understand the question; could you restate it?
I was talking about this point: " The suggestion to fix an interrupted rebase-i
or cherry-pick due to a commit that became empty via git reset HEAD (in
builtin/commit.c)
instead of git rebase --skip or git cherry-pick --skip ranges from annoying to
confusing.".
> > Points to work on:
> > --
> > - Add `git cherry-pick --skip`
>
> I'd reword this section as 'Consistently suggest --skip for operations
> that have such a concept'.[1]
Alright! I'll correct this in comming revisions.
> > - [Bonus] Deprecate am-based rebases
> > - [Bonus] Make a flag to allow rebase to rewrite commit messages that
> > refer to older commits that were also rebased
>
> I'd reorder these two. I suspect the second won't be too hard and
> will provide a new user-visible feature, while the former will
> hopefully not be visible to users; if the former has more than
> cosmetic differences visible to user, it might transform the problem
> into more of a social problem than a technical one or just make into
> something we can't do.
There is no "order" in these points, just a rough TODO list, but I get your
point here.
> > Proposed Timeline
> > -
> > + Community Bonding (May 6th - May 26th):
> > - Introduction to community
> > - Get familiar with the workflow
> > - Study and understand the workflow and implementation of the
> > project in detail
> >
> > + Phase 1 (May 27th - June 23rd):
> > - Start with implementing `git cherry-pick --skip`
> > - Write new tests for the just introduced flag(s)
> > - Analyse the requirements and differences of am-based and other
> > rebases flags
>
> Writing or finding tests to trigger all the --skip codepaths might be
> the biggest part of this phase. Implementing `git cherry-pick --skip`
> just involves making it run the code that `git reset` invokes. The
> you change the error message to reference ` --skip` instead
> of `git reset`. What you're calling phase 1 here isn't quite
> microproject sized, but it should be relatively quick and easy; I'd
> plan to spend much more of your time on phase 2.
>
> > + Phase 2 (June 24th - July 21st):
> > - Introduce flags of am-based rebases to other kinds.
> > - Add tests for the same.
>
> You should probably mention the individual cases from "INCOMPATIBLE
> FLAGS" of the git rebase manpage. Also, some advice for order of
> tackling these: I think you should probably do --ignore-whitespace
> first; my guess is that one is the easiest. Close up would be
> --committer-date-is-author-date and --ignore-date. Re-reading, I'm
> not sure -C even makes sense at all; it might be that the solution is
> just accepting the flag and ignoring it, or perhaps it remains the one
> flag the interactive backend won't support, or maybe there is
> something that makes sense to be done. There'd need to be a little
> investigation for that one, but it might turn out simple too. The
> --whitespace={nowarn|warn|fix|error|error-all} flag will be the
> kicker. I don't know how long that one will take, but I'm certain
> it's harder than the other flags and it might conceivably take up most
> the summer or even extend beyond.
>
> > + Phase 3 (July 22th - August 19th):
> > - Act on [Bonus] features
> > - Documentation
> > - Clean up tasks
>
> I'd prefer that Documentation updates were made as you went; you'll
> particularly need to look at Documentation/git-cherry-pick.txt and
> Documentation/rebase.txt, especially the "INCOMPATIBLE OPTIONS" and
> "BEHAVIORAL DIFFERENCES" sections of the latter.
Thanks for advice, yes, of course, the documentation and implementation will go
hand in hand.
> Also, as far as timing goes, the rewriting of commit messages seems
> relatively straightforward; you may want to consider doing it before
> the --whitespace flag (despite the fact that I originally suggested it
> as a bonus item). Deprecating am-based rebases, on the other hand, is
> a bit of a wildcard. It depends on Phase 2 being completed so it
> definitely makes sense to be last. If phase 2 is complete, it's
> conceivable that deprecating am-based rebases only takes a little more
> work, but it might expand to use up a lot of time.
>
> > Relevant Work
> > =
> > Dscho and I had a talk on how a non-am backend should implement `git rebase
> > --whitespace=fix`, which he warned may become a large project (as it turns
> > out it is a sub-task in one of the proposed ideas[0]), we were trying to
> > integrate this on git-for-windows first.
> > Keeping warning in mind, I discussed this project
Re: [PATCH] Make stashing nothing exit 1
On Sat, Mar 23, 2019 at 3:54 AM Ævar Arnfjörð Bjarmason
wrote:
> On Sat, Mar 23 2019, Keith Smiley wrote:
> > In the case there are no files to stash, but the user asked to stash, we
> > should exit 1 since the stashing failed.
> > ---
> > diff --git a/git-stash.sh b/git-stash.sh
> > @@ -318,7 +318,7 @@ push_stash () {
> > if no_changes "$@"
> > then
> > say "$(gettext "No local changes to save")"
> > - exit 0
> > + exit 1
> > fi
>
> * Shouldn't we do this consistently across all the other sub-commands?
>Trying some of them seems 'push' may be the odd one out, but maybe
>I've missed some (and this would/should be covered by
>tests). I.e. some single test that does a bunch of ops with no
>entries / nothing to stash and asserts exit codes.
A bigger question is why is this change desirable? What is the
justification for turning this into an error and possibly breaking
existing automation scripts? Arguing that this case should be an
"error" is difficult considering that there are many other commands
(inside and outside of Git) which exit with 0 when they have nothing
to do. I can't find the message in the archive right now, but I recall
a few months ago Junio shooting down an analogous change to some other
command, so the justification needs to be a strong one.
Also, your Signed-off-by: is missing. See
Documentation/SubmittingPatches. Thanks.
Re: [PATCH 1/3] rebase: teach rebase --keep-base
On Sat, Mar 23, 2019 at 11:25 AM Denton Liu wrote:>
> [...]
> Since rebasing onto the merge base of the branch and the upstream is
> such a common case, introduce the --keep-base option as a shortcut.
> [...]
> Signed-off-by: Denton Liu
> ---
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> @@ -1541,10 +1551,19 @@ int cmd_rebase(int argc, const char **argv, const
> char *prefix)
> /* Make sure the branch to rebase onto is valid. */
> - if (!options.onto_name)
> + if (keep_base) {
> + strbuf_reset(&buf);
> + strbuf_addstr(&buf, options.upstream_name);
> + strbuf_addstr(&buf, "...");
> + options.onto_name = xstrdup(buf.buf);
> + } else if (!options.onto_name)
> options.onto_name = options.upstream_name;
> if (strstr(options.onto_name, "...")) {
> if (get_oid_mb(options.onto_name, &merge_base) < 0)
> + if (keep_base)
> + die(_("'%s': need exactly one merge base with
> branch"),
> + options.upstream_name);
> + else
Style: Indent with tabs, not spaces.
