* Re: Git: new feature suggestion
From: Joao Pinto @ 2017-01-19 21:51 UTC (permalink / raw)
To: Linus Torvalds, Joao Pinto
Cc: Konstantin Khomoutov, Git Mailing List,
CARLOS.PALMINHA@synopsys.com
In-Reply-To: <CA+55aFzGaxhRRHXUcfnUDcgyaAKy4jXLcKMXH8T61x8sxEJT+g@mail.gmail.com>
Às 7:16 PM de 1/19/2017, Linus Torvalds escreveu:
> On Thu, Jan 19, 2017 at 10:54 AM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>
>> I am currently facing some challenges in one of Linux subsystems where a rename
>> of a set of folders and files would be the perfect scenario for future
>> development, but the suggestion is not accepted, not because it's not correct,
>> but because it makes the maintainer life harder in backporting bug fixes and new
>> features to older kernel versions and because it is not easy to follow the
>> renamed file/folder history from the kernel.org history logs.
>
> Honestly, that's less of a git issue, and more of a "patch will not
> apply across versions" issue.
>
> No amount of rename detection will ever fix that, simply because the
> rename hadn't even _happened_ in the old versions that things get
> backported to.
>
> ("git cherry-pick" can do a merge resolution and thus do "backwards"
> renaming too, so tooling can definitely help, but it still ends up
> meaning that even trivial patches are no longer the _same_ trivial
> patch across versions).
>
> So renaming things increases maintainer workloads in those situations
> regardless of any tooling issues.
>
> (You may also be referring to the mellanox mess, where this issue is
> very much exacerbated by having different groups working on the same
> thing, and maintainers having very much a "I will not take _anything_
> from any of the groups that makes my life more complicated" model,
> because those groups fucked up so much in the past).
>
> In other words, quite often issues are about workflows rather than
> tools. The networking layer probably has more of this, because David
> actually does the backports himself, so he _really_ doesn't want to
> complicate things.
I totally understand David' side! Synopsys is a well-known IP Vendor, and for a
long time its focus was the IP only. Knowadays the strategy has changed and
Synopsys is very keen to help in Open Source, namelly Linux, developing the
drivers for new IP Cores and participating in the improvement of existing ones.
I am part of the team that has that job.
In USB and PCI subystems developers created common Synopsys drivers (focused on
the HW IP) and so today they are massively used by all the SoC that use Synopsys
IP.
In the network subsystem, there are some drivers that target the same IP but
were made by different companies. stmmac is an excelent driver for Synopsys MAC
10/100/1000/QOS IPs, but there was another driver made by AXIS driver that also
targeted the QOS IP. We detected that issue and merged the AXIS specific driver
ops to stmmac, and nowadays, AXIS uses stmmac. So less drivers to maintain!
The idea that was rejected consisted of renaming stmicro/stmmac to dwc/stmmac
and to have dwc (designware controllers) as the official driver spot for
Synopsys Ethernet IPs.
There is another example of duplication, which is AMD' and Samsung' XGMAC
driver, targeting the same Synopsys XGMAC IP.
I am giving this examples because although the refactor adds work for
backporting, it reduces the maintenance since we would have less duplicated
drivers as we have today.
Thanks,
Joao
> Linus
>
^ permalink raw reply
* Re: merge maintaining history
From: Philip Oakley @ 2017-01-19 21:58 UTC (permalink / raw)
To: Jacob Keller, David J. Bakeman; +Cc: Git mailing list
In-Reply-To: <5880BB23.8030702@comcast.net>
From: "David J. Bakeman" <nakuru@comcast.net>
> On 01/14/2017 10:24 PM, Jacob Keller wrote:
>> On Fri, Jan 13, 2017 at 6:01 PM, David J. Bakeman <nakuru@comcast.net>
>> wrote:
>>> History
>>>
>>> git cloned a remote repository and made many changes pushing them all to
>>> said repository over many months.
>>>
>>> The powers that be then required me to move project to new repository
>>> server did so by pushing local version to new remote saving all history!
>>>
>>> Now have to merge back to original repository(which has undergone many
>>> changes since I split off) but how do I do that without loosing the
>>> history of all the commits since the original move? Note I need to push
>>> changes to files that are already in existence. I found on the web a
>>> bunch of ways to insert a whole new directory structure into an existing
>>> repository but as I said I need to do it on top of existing files. Of
>>> course I can copy all the files from my local working repository to the
>>> cloned remote repository and commit any changes but I loose all the
>>> history that way.
>>>
>>> Thanks.
>> If I understand it.. you have two remotes now:
>>
>> The "origin" remote, which was the original remote you started with.
>>
>> You have now a "new" remote which you created and pushed to.
>>
>> So you want to merge the "new" history into the original tree now, so
>> you checkout the original tree, then "git merge <new-remote>/<branch>"
>> and then fix up any conflicts, and then git commit to create a merge
>> commit that has the new history. Then you could push that to both
>> trees.
>>
>> I would want a bit more information about your setup before providing
>> actual commands.
> Thanks I think that's close but it's a little more complicated I think
> :<( I don't know if this diagram will work but lets try.
>
> original A->B->C->D->E->F
> \
> first branch b->c->d->e
>
> new repo e->f->g->h
>
> Now I need to merge h to F without loosing b through h hopefully. Yes e
> was never merged back to the original repo and it's essentially gone now
> so I can't just merge to F or can I?
a quick bikeshed..
You have both repositories, so nothing is lost.
Do note that 'e' commit sha1 in the first branch will be different from the
sha1 of 'e' commit in the new repo, but both should have the same top level
tree if they are truly identical.
You can fetch both repositories into a single common repo so you will have
an --orphan branch of the new repo.
Consider adding a --allow-empty commit e' to the original repo to note what
happens next (and how to do it), which is to use the replace mechanism to
bridge the gap between the e of the old repo and the e of the new repo by
making e of the new repo replace the e' you just created.
This will make it look like 'h' is the natural development of 'a'. Even if e
& e were not tree-same, you will be able to see a diff. You can now merge
'h' onto 'F' in whatever way you find appropriate to give the right view of
the development.
When you push this back upstream, note that the 'replace' is local, so
upstream sees a gap, but that commit e' has the instructions to rebuild the
link, should others require it (you may have to push the e' commit
separately).
--
Philip
^ permalink raw reply
* Re: Git: new feature suggestion
From: Stefan Beller @ 2017-01-19 22:03 UTC (permalink / raw)
To: Joao Pinto
Cc: Linus Torvalds, Konstantin Khomoutov, Git Mailing List,
CARLOS.PALMINHA@synopsys.com
In-Reply-To: <5207b04e-5e80-7100-4328-7e87ee619aea@synopsys.com>
On Thu, Jan 19, 2017 at 1:51 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
> Às 7:16 PM de 1/19/2017, Linus Torvalds escreveu:
>> On Thu, Jan 19, 2017 at 10:54 AM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>
>>> I am currently facing some challenges in one of Linux subsystems where a rename
>>> of a set of folders and files would be the perfect scenario for future
>>> development, but the suggestion is not accepted, not because it's not correct,
>>> but because it makes the maintainer life harder in backporting bug fixes and new
>>> features to older kernel versions and because it is not easy to follow the
>>> renamed file/folder history from the kernel.org history logs.
>>
>> Honestly, that's less of a git issue, and more of a "patch will not
>> apply across versions" issue.
>>
>> No amount of rename detection will ever fix that, simply because the
>> rename hadn't even _happened_ in the old versions that things get
>> backported to.
>>
>> ("git cherry-pick" can do a merge resolution and thus do "backwards"
>> renaming too, so tooling can definitely help, but it still ends up
>> meaning that even trivial patches are no longer the _same_ trivial
>> patch across versions).
>>
>> So renaming things increases maintainer workloads in those situations
>> regardless of any tooling issues.
>>
>> (You may also be referring to the mellanox mess, where this issue is
>> very much exacerbated by having different groups working on the same
>> thing, and maintainers having very much a "I will not take _anything_
>> from any of the groups that makes my life more complicated" model,
>> because those groups fucked up so much in the past).
>>
>> In other words, quite often issues are about workflows rather than
>> tools. The networking layer probably has more of this, because David
>> actually does the backports himself, so he _really_ doesn't want to
>> complicate things.
>
> I totally understand David' side! Synopsys is a well-known IP Vendor, and for a
> long time its focus was the IP only. Knowadays the strategy has changed and
> Synopsys is very keen to help in Open Source, namelly Linux, developing the
> drivers for new IP Cores and participating in the improvement of existing ones.
> I am part of the team that has that job.
>
> In USB and PCI subystems developers created common Synopsys drivers (focused on
> the HW IP) and so today they are massively used by all the SoC that use Synopsys
> IP.
>
> In the network subsystem, there are some drivers that target the same IP but
> were made by different companies. stmmac is an excelent driver for Synopsys MAC
> 10/100/1000/QOS IPs, but there was another driver made by AXIS driver that also
> targeted the QOS IP. We detected that issue and merged the AXIS specific driver
> ops to stmmac, and nowadays, AXIS uses stmmac. So less drivers to maintain!
>
> The idea that was rejected consisted of renaming stmicro/stmmac to dwc/stmmac
> and to have dwc (designware controllers) as the official driver spot for
> Synopsys Ethernet IPs.
> There is another example of duplication, which is AMD' and Samsung' XGMAC
> driver, targeting the same Synopsys XGMAC IP.
>
> I am giving this examples because although the refactor adds work for
> backporting, it reduces the maintenance since we would have less duplicated
> drivers as we have today.
This sounds as if the code in question would only receive backports
for a specific
time (determined by HW lifecycle, maintenance life cycle and such).
So I wonder if this could be solved by not just renaming but
additionally adding a
symbolic link, such that the files in question seem to appear twice on
the file system.
Then backports ought to be applicable (hoping git-am doesn't choke on symlinks),
and after a while once the there no backports any more (due to life
cycle reasons),
remove the link?
This also sounds like a kind of problem, that others have run into before,
how did they solve it?
Thanks,
Stefan
>
> Thanks,
> Joao
>
>
>> Linus
>>
>
^ permalink raw reply
* Re: [RFC for GIT] pull-request: add praise to people doing QA
From: Wolfram Sang @ 2017-01-19 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <xmqq7f5qzqx3.fsf@gitster.mtv.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]
> > I didn't know about trailers before. As I undestand it, I could use
> > "Tested-by" as the key, and the commit subject as the value. This list
> > then could be parsed and brought into proper output shape. It would
> > simplify the subject parsing, but most things my AWK script currently
> > does would still need to stay or to be reimplemented (extracting names
> > from tags, creating arrays of tags given by $name). Am I correct?
>
> That is not exactly what I had in mind. I was wondering if we can
> do without any external script, implementing the logic you added
> inside shortlog with an extra option that triggers the whole thing,
> which may call into the same trailers API as used by the
> interpret-trailers command to do the parsing and picking out parts.
Sorry for being unclear. That's what I meant with "or to be
reimplemented". I should have added "in C".
I am afraid this also requires more time than I am willing to
spend on this issue. Seems my hack is going to stay for a while here.
However, thank you for your time and assisting me with pointers!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RESEND PATCHv2] contrib: remove git-convert-objects
From: Stefan Beller @ 2017-01-19 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org, Linus Torvalds
In-Reply-To: <xmqqo9z2zs2o.fsf@gitster.mtv.corp.google.com>
On Thu, Jan 19, 2017 at 12:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> git-convert-objects, originally named git-convert-cache was used in
>> early 2005 to convert to a new repository format, e.g. adding an author
>> date.
>
> I think this description is not wrong per-se but misses the much
> more important point. In the very early days of Git, the objects
> were named after SHA-1 of deflated loose object representation,
> which meant that tweak in zlib or change of compression level would
> give the same object different names X-<. This program was to
> convert an ancient history with these objects and rewrite them to
> match the new object naming scheme where the name comes from a hash
> of the inflated representation.
ok, in case I reroll again, I'll fixup the message.
>
>> By now the need for conversion of the very early repositories is less
>> relevant, we no longer need to keep it in contrib; remove it.
>
> I am not sure if removal of it matters, and I suspect that we saw no
> reaction from anybody because nobody thought it deserves the
> brain-cycle to decide whether to remove it. I dunno.
I do think removing this would improve contrib/, not just because
it would better align with contribs mission statement in its README, but
also for other reasons. Why would a user look into contrib/ at all?
* to find interesting contemporary bits and pieces
* if they want to find old stuff for educational purposes, they ought to
be looking into contrib/examples instead.
So maybe instead of this patch, just move it to the examples section?
(That way we archive the same goal: a cleaner, fresher contrib/
that doesn't look as stale)
Thanks,
Stefan
^ permalink raw reply
* Re: grep open pull requests
From: Jack Bates @ 2017-01-19 22:12 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20170119190227.opjisryyqn766tqy@sigill.intra.peff.net>
On 19/01/17 12:02 PM, Jeff King wrote:
> It's much trickier to find from the git topology whether a particular
> history contains rebased versions of commits. You can look at the
> --cherry options to "git log", which use patch-ids to try to equate
> commits. Something like:
>
> git for-each-ref --format='%(refname)' 'refs/pull/*/head' |
> while read refname; do
> if test -z "$(git rev-list --right-only --cherry-pick -1 origin...$refname)
> then
> echo "$refname: not merged"
> fi
> done
>
> That's obviously much less efficient than `--no-merged`, but it should
> generally work. The exception is if the rebase changed the commit
> sufficiently that its patch-id may have changed.
Cool, thanks for all your help! "git log --cherry-pick" works quite
well. One thing: I expected the following to be equivalent, but found
that they're not. Is that by accident or design?
$ git rev-list --cherry-pick --right-only master...refs/pull/1112/head
$ git rev-list --cherry-pick master..refs/pull/1112/head
> I think that's probably the best answer to your "unmerged" question,
> too. Ask the API which PRs are unmerged, and then do whatever git-level
> analysis you want based on that.
Right, that makes sense. Thanks again!
^ permalink raw reply
* Re: grep open pull requests
From: Jeff King @ 2017-01-19 22:24 UTC (permalink / raw)
To: Jack Bates; +Cc: git
In-Reply-To: <9f59c0d7-73d3-1b4c-65ca-700d6e1f4f23@nottheoilrig.com>
On Thu, Jan 19, 2017 at 03:12:53PM -0700, Jack Bates wrote:
> Cool, thanks for all your help! "git log --cherry-pick" works quite well.
> One thing: I expected the following to be equivalent, but found that they're
> not. Is that by accident or design?
>
> $ git rev-list --cherry-pick --right-only master...refs/pull/1112/head
> $ git rev-list --cherry-pick master..refs/pull/1112/head
It's by design. The "left" and "right" notions are defined only for a
three-dot symmetric difference.
In the first command you've asked git to look at commits on _both_
master and the PR, down to their merge base. It marks the tips with a
"left" and "right" bit, and then those bits propagate down.
In the second command, you've only asked for the PR commits, and there
is no left/right bit at all. So --cherry-pick is doing nothing, as it
has no "left" commits to compare to.
-Peff
^ permalink raw reply
* Re: submodule network operations [WAS: Re: [RFC/PATCH 0/4] working tree operations: support superprefix]
From: Brian J. Davis @ 2017-01-19 23:11 UTC (permalink / raw)
To: Stefan Beller; +Cc: Brandon Williams, git@vger.kernel.org, David Turner
In-Reply-To: <CAGZ79kaf0BhbnJGhkjT_Ys44y4c4AaxV8U_ydWp4bbFMkGRcsQ@mail.gmail.com>
On 1/17/2017 12:43 PM, Stefan Beller wrote:
> On Sun, Jan 15, 2017 at 1:02 PM, Brian J. Davis <bitminer@gmail.com> wrote:
>
>>> Technically it is submodule.<name>.url instead of
>>> submodule.<path>.url. The name is usually the path initially, and once
>>> you move the submodule, only the path changes, the name is supposed to
>>> be constant and stay the same.
>> I am not certain what is meant by this. All I know is I can use my
>> "directory_to_checkout" above to place in tree relative from root the
>> project any where in the tree not already tracked by git. You state name
>> instead of path, but it allows path correct? Either that or I have gone off
>> reservation with my use of git for years now. Maybe this is a deviation from
>> how it is documented/should work and how it actually works? It works great
>> how I use it.
> Yes name can equal the path (and usually does). This is a minor detail
> that is only relevant for renaming submodules, so ... maybe let's not
> focus on it too much. :)
>
>>>>
>>>> but if say I want to pull from some server 2 and do a
>>>>
>>>> git submodule update --init --recursive
>>> That is why the "git submodule init" exists at all.
>>>
>>> git submodule init
>>> $EDIT .git/config # change submodule.<name>.url to server2
>>> git submodule update # that uses the adapted url and
>>> # creates the submodule repository.
>>>
>>> # From now on the submodule is on its own.
>>> cd <submodule> && git config --list
>>> # prints an "origin" remote and a lot more
>>>
>>> For a better explanation, I started a documentation series, see
>>>
>>> https://github.com/gitster/git/commit/e2b51b9df618ceeff7c4ec044e20f5ce9a87241e
>>>
>>> (It is not finished, but that is supposed to explain this exact pain
>>> point in the
>>> STATES section, feel free to point out missing things or what is hard
>>> to understand)
>> I am not sure I got much out of the STATES section regarding my problem.
> Your original problem as far as I understand is this:
>
> You have a project with submodules.
> The submodules are described in the .gitmodules file.
> But the URL is pointing to an undesired location.
> You want to rewrite the URLs before actually cloning the submodules.
>
> And to solve this problem we need to perform multiple steps:
>
> # --no is the default, just for clarity here:
> git clone <project> --no-recurse-submodules
> # The submodules are now in the *uninitialized* state
>
> git submodule init
> # the submodules are in the initialized state
>
> git submodule update
> # submodules are populated, i.e. cloned from
> # the configured URLs and put into the working tree at
> # the appropriate path.
>
> Between the init and the update step you can modify the URLs.
> These commands are just a repetition from the first email, but the
> git commands can be viewed as moving from one state to another
> for submodules; submodules itself can be seen as a state machine
> according to that proposed documentation. Maybe such a state machine
> makes it easier to understand for some people.
"Between the init and the update step you can modify the URLs." Yes I can and have to... wish it was not this way.
>>>> what I would get is from someserver1 not someserver2 as there is no
>>>> "origin"
>>>> support for submodules. Is this correct? If so can origin support be
>>>> added
>>>> to submodules?
>>> Can you explain more in detail what you mean by origin support?
>> Yes so when we do a:
>>
>> git push origin master
>>
>> origin is of course the Remote (Remotes
>> https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes)
>>
>> So I best use terminology "Remotes" support. Git push supports remotes, but
>> git submodules does not. The basic idea is this:
>>
>> If Git allowed multiple submodule
>> (https://git-scm.com/book/en/v2/Git-Tools-Submodules) Remotes to be
>> specified say as an example:
>>
>> git submodule add [remote] [url]
>>
>> git submodule add origin https://github.com/chaconinc/DbConnector
>> git submodule add indhouse https://indhouse .corp/chaconinc/DbConnector
>>
>> Where:
>>
>> [submodule "DbConnector"]
>> path = DbConnector
>> url = https://github.com/chaconinc/DbConnector
>>
>> Could then change to:
>>
>> [submodule "DbConnector"]
>> path = DbConnector
>> remote.origin.url = https://github.com/chaconinc/DbConnector
>> remote.origin.url = https://indhouse .corp/chaconinc/DbConnector
> here I assume there is a typo and the second remote.origin.url should be
> remote.inhouse.url ?
yes second should have read remote.inhouse.url:
[submodule "DbConnector"]
path = DbConnector
remote.origin.url = https://github.com/chaconinc/DbConnector
remote.inhouse.url = https://indhouse.corp/chaconinc/DbConnector
>>
>> Then it should be possible to get:
>>
>> git submodules update --init --recursive
> which would setup the submodule with both
>
> [remote "origin"]
> url = https://github.com/..
> [remote "inhouse"]
> url = https://inhouse.corp/..
>
> But where do we clone it from?
> (Or do we just do a "git init" on that submodule and fetch
> from both remotes? in which order?)
origin by default and inhouse if specified. There is already a implied
default (origin). The idea was not to do both but rather what is
specified. Origin and inhouse are just names for remotes. If one wanted
a "--all-remotes" could pull from everywhere in the Ether if feature was
to be implemented.
>> To support
>>
>> git submodules update [remote] --init --recursive
> This would just clone/fetch from the specified remote?
> If implementing this, we may run into a collision with the
> specified submodules, what if a submodule is at
> path "origin" ?
>
> Does "git submodule update origin --init --recursive"
> then mean to update the single "origin" submodule or
> all submodules from their origin remote?
Yes. That is what I would think. It does this already by default. It's
not as though submodules were/are all that well thought out to begin
with in git IMO.
>> And thus allow
>>
>> git submodules update origin --init --recursive
>>
>> git submodules update indhouse --init --recursive
> understood. I like the idea of being able to specify
> multiple remotes from the superproject..
Yes so do I! It *could* be better than the current offering which is
defaulted origin.
^ permalink raw reply
* Re: [PATCH v4 2/5] name-rev: extend --refs to accept multiple patterns
From: Jacob Keller @ 2017-01-19 23:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jacob Keller, Git mailing list, Johannes Sixt,
Johannes Schindelin
In-Reply-To: <xmqqfukezrmh.fsf@gitster.mtv.corp.google.com>
On Thu, Jan 19, 2017 at 1:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jacob Keller <jacob.e.keller@intel.com> writes:
>
>> From: Jacob Keller <jacob.keller@gmail.com>
>>
>> Teach git name-rev to take multiple --refs stored as a string list of
>> patterns. The list of patterns will be matched inclusively, and each ref
>> only needs to match one pattern to be included. A ref will only be
>> excluded if it does not match any of the given patterns. Additionally,
>> if any of the patterns would allow abbreviation, then we will abbreviate
>> the ref, even if another pattern is more strict and would not have
>> allowed abbreviation on its own.
>>
>> Add tests and documentation for this change. The tests expected output
>> is dynamically generated, but this is in order to avoid hard-coding
>> a commit object id in the test results (as the expected output is to
>> simply leave the commit object unnamed).
>
> Makes sense.
>
> I do not see anything that requires "... generated, but" there,
> though, as if it is a bad thing to do to prepare expected output
> dynamically. I'd just reword "generated. This is..." to make it
> neutral.
Makes sense. I was commenting this way since I was requested that
someone on the list preferred non-dynamic test expectations.
Thanks,
Jake
^ permalink raw reply
* What's cooking in git.git (Jan 2017, #03; Thu, 19)
From: Junio C Hamano @ 2017-01-19 23:37 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The sixth batch of topics have been merged to 'master'. This batch
is fairly large, and regression-hunting is very much appreciated.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* bw/grep-recurse-submodules (2016-12-22) 12 commits
(merged to 'next' on 2016-12-22 at 1ede815b8d)
+ grep: search history of moved submodules
+ grep: enable recurse-submodules to work on <tree> objects
+ grep: optionally recurse into submodules
+ grep: add submodules as a grep source type
+ submodules: load gitmodules file from commit sha1
+ submodules: add helper to determine if a submodule is initialized
+ submodules: add helper to determine if a submodule is populated
(merged to 'next' on 2016-12-22 at fea8fa870f)
+ real_path: canonicalize directory separators in root parts
+ real_path: have callers use real_pathdup and strbuf_realpath
+ real_path: create real_pathdup
+ real_path: convert real_path_internal to strbuf_realpath
+ real_path: resolve symlinks by hand
(this branch is tangled with bw/realpath-wo-chdir.)
"git grep" has been taught to optionally recurse into submodules.
* bw/pathspec-cleanup (2017-01-08) 16 commits
(merged to 'next' on 2017-01-10 at 79291ff506)
+ pathspec: rename prefix_pathspec to init_pathspec_item
+ pathspec: small readability changes
+ pathspec: create strip submodule slash helpers
+ pathspec: create parse_element_magic helper
+ pathspec: create parse_long_magic function
+ pathspec: create parse_short_magic function
+ pathspec: factor global magic into its own function
+ pathspec: simpler logic to prefix original pathspec elements
+ pathspec: always show mnemonic and name in unsupported_magic
+ pathspec: remove unused variable from unsupported_magic
+ pathspec: copy and free owned memory
+ pathspec: remove the deprecated get_pathspec function
+ ls-tree: convert show_recursive to use the pathspec struct interface
+ dir: convert fill_directory to use the pathspec struct interface
+ dir: remove struct path_simplify
+ mv: remove use of deprecated 'get_pathspec()'
(this branch is used by sb/pathspec-errors.)
Code clean-up in the pathspec API.
* bw/realpath-wo-chdir (2017-01-09) 7 commits
(merged to 'next' on 2017-01-10 at ed315a40c8)
+ real_path: set errno when max number of symlinks is exceeded
+ real_path: prevent redefinition of MAXSYMLINKS
(merged to 'next' on 2016-12-22 at fea8fa870f)
+ real_path: canonicalize directory separators in root parts
+ real_path: have callers use real_pathdup and strbuf_realpath
+ real_path: create real_pathdup
+ real_path: convert real_path_internal to strbuf_realpath
+ real_path: resolve symlinks by hand
(this branch is tangled with bw/grep-recurse-submodules.)
The implementation of "real_path()" was to go there with chdir(2)
and call getcwd(3), but this obviously wouldn't be usable in a
threaded environment. Rewrite it to manually resolve relative
paths including symbolic links in path components.
* dt/disable-bitmap-in-auto-gc (2016-12-29) 2 commits
(merged to 'next' on 2017-01-10 at 9f4e89e15d)
+ repack: die on incremental + write-bitmap-index
+ auto gc: don't write bitmaps for incremental repacks
It is natural that "git gc --auto" may not attempt to pack
everything into a single pack, and there is no point in warning
when the user has configured the system to use the pack bitmap,
leading to disabling further "gc".
* jk/archive-zip-userdiff-config (2017-01-07) 1 commit
(merged to 'next' on 2017-01-10 at ac42e4958c)
+ archive-zip: load userdiff config
"git archive" did not read the standard configuration files, and
failed to notice a file that is marked as binary via the userdiff
driver configuration.
* jk/blame-fixes (2017-01-07) 3 commits
(merged to 'next' on 2017-01-10 at 18f909da61)
+ blame: output porcelain "previous" header for each file
+ blame: handle --no-abbrev
+ blame: fix alignment with --abbrev=40
"git blame --porcelain" misidentified the "previous" <commit, path>
pair (aka "source") when contents came from two or more files.
* jk/execv-dashed-external (2017-01-09) 3 commits
(merged to 'next' on 2017-01-10 at 117b506cb0)
+ execv_dashed_external: wait for child on signal death
+ execv_dashed_external: stop exiting with negative code
+ execv_dashed_external: use child_process struct
Typing ^C to pager, which usually does not kill it, killed Git and
took the pager down as a collateral damage in certain process-tree
structure. This has been fixed.
* jk/rebase-i-squash-count-fix (2017-01-07) 1 commit
(merged to 'next' on 2017-01-10 at d6cfc6ace2)
+ rebase--interactive: count squash commits above 10 correctly
"git rebase -i" with a recent update started showing an incorrect
count when squashing more than 10 commits.
* js/asciidoctor-tweaks (2017-01-13) 2 commits
(merged to 'next' on 2017-01-15 at 8553c6e513)
+ asciidoctor: fix user-manual to be built by `asciidoctor`
(merged to 'next' on 2017-01-10 at 087da7b7c1)
+ giteveryday: unbreak rendering with AsciiDoctor
Adjust documentation to help AsciiDoctor render better while not
breaking the rendering done by AsciiDoc.
* js/mingw-test-push-unc-path (2017-01-07) 1 commit
(merged to 'next' on 2017-01-10 at 249d9f26f3)
+ mingw: add a regression test for pushing to UNC paths
"git push \\server\share\dir" has recently regressed and then
fixed. A test has retroactively been added for this breakage.
* km/branch-get-push-while-detached (2017-01-07) 1 commit
(merged to 'next' on 2017-01-10 at a7f8af8c55)
+ branch_get_push: do not segfault when HEAD is detached
"git <cmd> @{push}" on a detached HEAD used to segfault; it has
been corrected to error out with a message.
* ls/p4-retry-thrice (2016-12-29) 1 commit
(merged to 'next' on 2017-01-10 at c733e27410)
+ git-p4: do not pass '-r 0' to p4 commands
A recent updates to "git p4" was not usable for older p4 but it
could be made to work with minimum changes. Do so.
* pb/test-must-fail-is-for-git (2017-01-09) 2 commits
(merged to 'next' on 2017-01-10 at 5f24a98779)
+ t9813: avoid using pipes
+ don't use test_must_fail with grep
Test cleanup.
* rh/mergetool-regression-fix (2017-01-10) 14 commits
(merged to 'next' on 2017-01-10 at e8e00c798b)
+ mergetool: fix running in subdir when rerere enabled
+ mergetool: take the "-O" out of $orderfile
+ t7610: add test case for rerere+mergetool+subdir bug
+ t7610: spell 'git reset --hard' consistently
+ t7610: don't assume the checked-out commit
+ t7610: always work on a test-specific branch
+ t7610: delete some now-unnecessary 'git reset --hard' lines
+ t7610: run 'git reset --hard' after each test to clean up
+ t7610: don't rely on state from previous test
+ t7610: use test_when_finished for cleanup tasks
+ t7610: move setup code to the 'setup' test case
+ t7610: update branch names to match test number
+ rev-parse doc: pass "--" to rev-parse in the --prefix example
+ .mailmap: record canonical email for Richard Hansen
"git mergetool" without any pathspec on the command line that is
run from a subdirectory became no-op in Git v2.11 by mistake, which
has been fixed.
* sb/pathspec-errors (2017-01-09) 1 commit
(merged to 'next' on 2017-01-10 at 432375cb62)
+ pathspec: give better message for submodule related pathspec error
(this branch uses bw/pathspec-cleanup.)
Running "git add a/b" when "a" is a submodule correctly errored
out, but without a meaningful error message.
* sb/remove-gitview (2017-01-13) 4 commits
(merged to 'next' on 2017-01-15 at 7c9eae479e)
+ doc: git-gui browser does not default to HEAD
+ doc: gitk: add the upstream repo location
+ doc: gitk: remove gitview reference
(merged to 'next' on 2017-01-10 at dcb3abd146)
+ contrib: remove gitview
Retire long unused/unmaintained gitview from the contrib/ area.
* sb/submodule-cleanup-export-git-dir-env (2017-01-07) 1 commit
(merged to 'next' on 2017-01-10 at 2d5db6821e)
+ submodule.c: use GIT_DIR_ENVIRONMENT consistently
Code cleanup.
* sb/submodule-rm-absorb (2016-12-27) 4 commits
(merged to 'next' on 2017-01-10 at 1fc2000a92)
+ rm: absorb a submodules git dir before deletion
+ submodule: rename and add flags to ok_to_remove_submodule
+ submodule: modernize ok_to_remove_submodule to use argv_array
+ submodule.h: add extern keyword to functions
"git rm" used to refuse to remove a submodule when it has its own
git repository embedded in its working tree. It learned to move
the repository away to $GIT_DIR/modules/ of the superproject
instead, and allow the submodule to be deleted (as long as there
will be no loss of local modifications, that is).
* sb/unpack-trees-cleanup (2017-01-10) 3 commits
(merged to 'next' on 2017-01-10 at 95a5f3127c)
+ unpack-trees: factor progress setup out of check_updates
+ unpack-trees: remove unneeded continue
+ unpack-trees: move checkout state into check_updates
Code cleanup.
* sp/cygwin-build-fixes (2017-01-09) 2 commits
(merged to 'next' on 2017-01-10 at 2010fb6c03)
+ Makefile: put LIBS after LDFLAGS for imap-send
+ Makefile: POSIX windres
Build updates for Cygwin.
--------------------------------------------------
[New Topics]
* jk/coding-guidelines-update (2017-01-17) 1 commit
- CodingGuidelines: clarify multi-line brace style
Developer doc update.
Will merge to 'next'.
* jk/fsck-connectivity-check-fix (2017-01-17) 6 commits
- fsck: check HAS_OBJ more consistently
- fsck: do not fallback "git fsck <bogus>" to "git fsck"
- fsck: tighten error-checks of "git fsck <head>"
- fsck: prepare dummy objects for --connectivity-check
- fsck: report trees as dangling
- t1450: clean up sub-objects in duplicate-entry test
"git fsck --connectivity-check" was not working at all.
Will merge to 'next'.
* js/exec-path-coverity-workaround (2017-01-09) 2 commits
- git_exec_path: do not return the result of getenv()
- git_exec_path: avoid Coverity warning about unfree()d result
Code cleanup.
Will merge to 'next'.
Split out of another topic.
* js/mingw-isatty (2017-01-18) 1 commit
- mingw: follow-up to "replace isatty() hack"
An update to a topic that is already in 'master'.
Will merge to 'next'.
* js/sequencer-i-countdown-3 (2017-01-17) 38 commits
- sequencer (rebase -i): write out the final message
- sequencer (rebase -i): write the progress into files
- sequencer (rebase -i): show the progress
- sequencer (rebase -i): suggest --edit-todo upon unknown command
- sequencer (rebase -i): show only failed cherry-picks' output
- sequencer (rebase -i): show only failed `git commit`'s output
- sequencer: use run_command() directly
- sequencer: update reading author-script
- sequencer (rebase -i): differentiate between comments and 'noop'
- sequencer (rebase -i): implement the 'drop' command
- sequencer (rebase -i): allow rescheduling commands
- sequencer (rebase -i): respect strategy/strategy_opts settings
- sequencer (rebase -i): respect the rebase.autostash setting
- sequencer (rebase -i): run the post-rewrite hook, if needed
- sequencer (rebase -i): record interrupted commits in rewritten, too
- sequencer (rebase -i): copy commit notes at end
- sequencer (rebase -i): set the reflog message consistently
- sequencer (rebase -i): refactor setting the reflog message
- sequencer (rebase -i): allow fast-forwarding for edit/reword
- sequencer (rebase -i): implement the 'reword' command
- sequencer (rebase -i): leave a patch upon error
- sequencer (rebase -i): update refs after a successful rebase
- sequencer (rebase -i): the todo can be empty when continuing
- sequencer (rebase -i): skip some revert/cherry-pick specific code path
- sequencer (rebase -i): remove CHERRY_PICK_HEAD when no longer needed
- sequencer (rebase -i): allow continuing with staged changes
- sequencer (rebase -i): write an author-script file
- sequencer (rebase -i): implement the short commands
- sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
- sequencer (rebase -i): write the 'done' file
- sequencer (rebase -i): learn about the 'verbose' mode
- sequencer (rebase -i): implement the 'exec' command
- sequencer (rebase -i): implement the 'edit' command
- sequencer (rebase -i): implement the 'noop' command
- sequencer: support a new action: 'interactive rebase'
- sequencer: use a helper to find the commit message
- sequencer: move "else" keyword onto the same line as preceding brace
- sequencer: avoid unnecessary curly braces
The sequencer machinery has been further enhanced so that a later
set of patches can start using it to reimplement "rebase -i".
I think I've said everything that needs to be said on this topic;
will wait for a few days and merge it to 'next', perhaps early next
week.
* jk/clear-delta-base-cache-fix (2017-01-19) 1 commit
- clear_delta_base_cache(): don't modify hashmap while iterating
A crashing bug introduced in v2.11 timeframe has been found (it is
triggerable only in fast-import) and fixed.
Will merge to 'next'.
* jk/describe-omit-some-refs (2017-01-19) 6 commits
- SQUASH???
- describe: teach describe negative pattern matches
- describe: teach --match to accept multiple patterns
- name-rev: add support to exclude refs by pattern match
- name-rev: extend --refs to accept multiple patterns
- doc: add documentation for OPT_STRING_LIST
"git describe" and "git name-rev" have been taught to take more
than one refname patterns to restrict the set of refs to base their
naming output on, and also learned to take negative patterns to
name refs not to be used for naming via their "--exclude" option.
Will merge to 'next' after making sure SQUASH??? is correctly
squashed in.
* js/remote-rename-with-half-configured-remote (2017-01-19) 2 commits
- remote rename: more carefully determine whether a remote is configured
- remote rename: demonstrate a bogus "remote exists" bug
With anticipatory tweaking for remotes defined in ~/.gitconfig
(e.g. "remote.origin.prune" set to true, even though there may or
may not actually be "origin" remote defined in a particular Git
repository), "git remote rename" and other commands misinterpreted
and behaved as if such a non-existing remote actually existed.
Will merge to 'next'.
* sb/in-core-index-doc (2017-01-19) 4 commits
- documentation: retire unfinished documentation
- cache.h: document add_[file_]to_index
- cache.h: document remove_index_entry_at
- cache.h: document index_name_pos
Documentation and in-code comments updates.
Will merge to 'next'.
* sb/retire-convert-objects-from-contrib (2017-01-19) 1 commit
- contrib: remove git-convert-objects
Remove an ancient tool left in contrib/.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
"git diff -B -M" produced incorrect patch when the postimage of a
completely rewritten file is similar to the preimage of a removed
file; such a resulting file must not be expressed as a rename from
other place.
The fix in this patch is broken, unfortunately.
Will discard.
--------------------------------------------------
[Cooking]
* bw/read-blob-data-does-not-modify-index-state (2017-01-11) 1 commit
(merged to 'next' on 2017-01-18 at f33363fb07)
+ index: improve constness for reading blob data
Code clean-up.
Will merge to 'master'.
* ep/commit-static-buf-cleanup (2017-01-13) 2 commits
- builtin/commit.c: switch to xstrfmt(), instead of snprintf()
- builtin/commit.c: remove the PATH_MAX limitation via dynamic allocation
Code clean-up.
Expecting a reroll.
The tip one would instead be done with strbuf.
cf. <CA+EOSB=4-TKpi6mr-yVbwRsFrVzE=vo4Y9Qm3VMm7pn=UB1_hQ@mail.gmail.com>
* jk/grep-e-could-be-extended-beyond-posix (2017-01-11) 1 commit
(merged to 'next' on 2017-01-18 at dd1b9d1fa8)
+ t7810: avoid assumption about invalid regex syntax
Tighten a test to avoid mistaking an extended ERE regexp engine as
a PRE regexp engine.
Will merge to 'master'.
* jk/vreport-sanitize (2017-01-11) 2 commits
(merged to 'next' on 2017-01-18 at 4bbf370981)
+ vreport: sanitize ASCII control chars
+ Revert "vreportf: avoid intermediate buffer"
An error message with an ASCII control character like '\r' in it
can alter the message to hide its early part, which is problematic
when a remote side gives such an error message that the local side
will relay with a "remote: " prefix.
Will merge to 'master'.
* sb/unpack-trees-super-prefix (2017-01-12) 5 commits
- SQUASH
- unpack-trees: support super-prefix option
- t1001: modernize style
- t1000: modernize style
- read-tree: use OPT_BOOL instead of OPT_SET_INT
"git read-tree" and its underlying unpack_trees() machinery learned
to report problematic paths prefixed with the --super-prefix option.
Expecting a reroll.
The first three are in good shape. The last one needs a better
explanation and possibly an update to its test.
cf. <CAGZ79kaHDnVLQr8WLoaD5KKs7EqeW=KbkptF=iHpU5t054Xcdw@mail.gmail.com>
* sb/submodule-config-tests (2017-01-12) 2 commits
(merged to 'next' on 2017-01-18 at bd850f6ad3)
+ t7411: test lookup of uninitialized submodules
+ t7411: quote URLs
Test updates.
Will merge to 'master'.
* sb/submodule-doc (2017-01-12) 3 commits
- submodules: add a background story
- submodule update documentation: don't repeat ourselves
- submodule documentation: add options to the subcommand
Needs review.
* sb/submodule-embed-gitdir (2017-01-12) 1 commit
(merged to 'next' on 2017-01-18 at 0a5e24a3f0)
+ submodule absorbgitdirs: mention in docstring help
Help-text fix.
Will merge to 'master'.
* sb/submodule-init (2017-01-12) 1 commit
(merged to 'next' on 2017-01-18 at 2e8a38b1cc)
+ submodule update --init: display correct path from submodule
Error message fix.
Will merge to 'master'.
* vn/diff-ihc-config (2017-01-12) 1 commit
(merged to 'next' on 2017-01-18 at ac4915dbe6)
+ diff: add interhunk context config option
"git diff" learned diff.interHunkContext configuration variable
that gives the default value for its --inter-hunk-context option.
Will merge to 'master'.
* ad/bisect-terms (2017-01-13) 1 commit
(merged to 'next' on 2017-01-18 at 9f500d6cf5)
+ Documentation/bisect: improve on (bad|new) and (good|bad)
Documentation fix.
Will merge to 'master'.
* bw/attr (2017-01-15) 27 commits
- attr: reformat git_attr_set_direction() function
- attr: push the bare repo check into read_attr()
- attr: store attribute stacks in hashmap
- attr: tighten const correctness with git_attr and match_attr
- attr: remove maybe-real, maybe-macro from git_attr
- attr: eliminate global check_all_attr array
- attr: use hashmap for attribute dictionary
- attr: change validity check for attribute names to use positive logic
- attr: pass struct attr_check to collect_some_attrs
- attr: retire git_check_attrs() API
- attr: convert git_check_attrs() callers to use the new API
- attr: convert git_all_attrs() to use "struct attr_check"
- attr: (re)introduce git_check_attr() and struct attr_check
- attr: rename function and struct related to checking attributes
- attr.c: outline the future plans by heavily commenting
- Documentation/gitattributes.txt: fix a typo
- attr.c: add push_stack() helper
- attr: support quoting pathname patterns in C style
- attr.c: plug small leak in parse_attr_line()
- attr.c: tighten constness around "git_attr" structure
- attr.c: simplify macroexpand_one()
- attr.c: mark where #if DEBUG ends more clearly
- attr.c: complete a sentence in a comment
- attr.c: explain the lack of attr-name syntax check in parse_attr()
- attr.c: update a stale comment on "struct match_attr"
- attr.c: use strchrnul() to scan for one line
- commit.c: use strchrnul() to scan for one line
The gitattributes machinery is being taught to work better in a
multi-threaded environment.
Needs review.
* jk/loose-object-fsck (2017-01-15) 6 commits
- fsck: detect trailing garbage in all object types
- fsck: parse loose object paths directly
- sha1_file: add read_loose_object() function
- t1450: test fsck of packed objects
- sha1_file: fix error message for alternate objects
- t1450: refactor loose-object removal
"git fsck" inspects loose objects more carefully now.
Will merge to 'next'.
* rh/diff-orderfile-doc (2017-01-15) 2 commits
(merged to 'next' on 2017-01-18 at cc2af9c628)
+ diff: document the format of the -O (diff.orderFile) file
+ diff: document behavior of relative diff.orderFile
Documentation fix.
Will merge to 'master'.
* sb/cd-then-git-can-be-written-as-git-c (2017-01-13) 1 commit
(merged to 'next' on 2017-01-18 at 8923d2d001)
+ lib-submodule-update.sh: reduce use of subshell by using "git -C"
Test clean-up.
Will merge to 'master'.
* vn/xdiff-func-context (2017-01-15) 1 commit
- xdiff -W: relax end-of-file function detection
"git diff -W" has been taught to handle the case where a new
function is added at the end of the file better.
Will hold.
An follow-up change to go back from the line that matches the
funcline to show comments before the function definition is still
being discussed.
* ws/request-pull-code-cleanup (2017-01-15) 1 commit
(merged to 'next' on 2017-01-18 at dfcb1405de)
+ request-pull: drop old USAGE stuff
Code clean-up.
Will merge to 'master'.
* mh/ref-remove-empty-directory (2017-01-07) 23 commits
- files_transaction_commit(): clean up empty directories
- try_remove_empty_parents(): teach to remove parents of reflogs, too
- try_remove_empty_parents(): don't trash argument contents
- try_remove_empty_parents(): rename parameter "name" -> "refname"
- delete_ref_loose(): inline function
- delete_ref_loose(): derive loose reference path from lock
- log_ref_write_1(): inline function
- log_ref_setup(): manage the name of the reflog file internally
- log_ref_write_1(): don't depend on logfile argument
- log_ref_setup(): pass the open file descriptor back to the caller
- log_ref_setup(): improve robustness against races
- log_ref_setup(): separate code for create vs non-create
- log_ref_write(): inline function
- rename_tmp_log(): improve error reporting
- rename_tmp_log(): use raceproof_create_file()
- lock_ref_sha1_basic(): use raceproof_create_file()
- lock_ref_sha1_basic(): inline constant
- raceproof_create_file(): new function
- safe_create_leading_directories(): set errno on SCLD_EXISTS
- safe_create_leading_directories_const(): preserve errno
- t5505: use "for-each-ref" to test for the non-existence of references
- refname_is_safe(): correct docstring
- files_rename_ref(): tidy up whitespace
Deletion of a branch "foo/bar" could remove .git/refs/heads/foo
once there no longer is any other branch whose name begins with
"foo/", but we didn't do so so far. Now we do.
Expecting a reroll.
cf. <5051c78e-51f9-becd-e1a6-9c0b781d6912@alum.mit.edu>
* ls/filter-process-delayed (2017-01-08) 1 commit
. convert: add "status=delayed" to filter process protocol
Ejected, as does not build when merged to 'pu'.
* nd/worktree-move (2017-01-09) 6 commits
- worktree remove: new command
- worktree move: refuse to move worktrees with submodules
- worktree move: accept destination as directory
- worktree move: new command
- worktree.c: add update_worktree_location()
- worktree.c: add validate_worktree()
"git worktree" learned move and remove subcommands.
Needs review.
* nd/log-graph-configurable-colors (2017-01-19) 4 commits
- SQUASH???
- log --graph: customize the graph lines with config log.graphColors
- color.c: trim leading spaces in color_parse_mem()
- color.c: fix color_parse_mem() with value_len == 0
Some people feel the default set of colors used by "git log --graph"
rather limiting. A mechanism to customize the set of colors has
been introduced.
Will merge to 'next' after making sure SQUASH??? is correctly
squashed in.
* cc/split-index-config (2016-12-26) 21 commits
- Documentation/git-update-index: explain splitIndex.*
- Documentation/config: add splitIndex.sharedIndexExpire
- read-cache: use freshen_shared_index() in read_index_from()
- read-cache: refactor read_index_from()
- t1700: test shared index file expiration
- read-cache: unlink old sharedindex files
- config: add git_config_get_expiry() from gc.c
- read-cache: touch shared index files when used
- sha1_file: make check_and_freshen_file() non static
- Documentation/config: add splitIndex.maxPercentChange
- t1700: add tests for splitIndex.maxPercentChange
- read-cache: regenerate shared index if necessary
- config: add git_config_get_max_percent_split_change()
- Documentation/git-update-index: talk about core.splitIndex config var
- Documentation/config: add information for core.splitIndex
- t1700: add tests for core.splitIndex
- update-index: warn in case of split-index incoherency
- read-cache: add and then use tweak_split_index()
- split-index: add {add,remove}_split_index() functions
- config: add git_config_get_split_index()
- config: mark an error message up for translation
The experimental "split index" feature has gained a few
configuration variables to make it easier to use.
Waiting for review comments to be addressed.
cf. <20161226102222.17150-1-chriscool@tuxfamily.org>
cf. <a1a44640-ff6c-2294-72ac-46322eff8505@ramsayjones.plus.com>
* bw/push-submodule-only (2016-12-20) 3 commits
- push: add option to push only submodules
- submodules: add RECURSE_SUBMODULES_ONLY value
- transport: reformat flag #defines to be more readable
"git submodule push" learned "--recurse-submodules=only option to
push submodules out without pushing the top-level superproject.
Will merge to 'next'.
* ls/p4-path-encoding (2016-12-18) 1 commit
- git-p4: fix git-p4.pathEncoding for removed files
When "git p4" imports changelist that removes paths, it failed to
convert pathnames when the p4 used encoding different from the one
used on the Git side. This has been corrected.
Will be rerolled.
cf. <7E1C7387-4F37-423F-803D-3B5690B49D40@gmail.com>
* js/difftool-builtin (2017-01-19) 3 commits
- difftool: retire the scripted version
- difftool: implement the functionality in the builtin
- difftool: add a skeleton for the upcoming builtin
Rewrite a scripted porcelain "git difftool" in C.
Will merge to 'next'.
* sb/push-make-submodule-check-the-default (2016-11-29) 2 commits
(merged to 'next' on 2016-12-12 at 1863e05af5)
+ push: change submodule default to check when submodules exist
+ submodule add: extend force flag to add existing repos
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Will cook in 'next'.
* kn/ref-filter-branch-list (2017-01-10) 21 commits
- SQUASH???
- branch: implement '--format' option
- branch: use ref-filter printing APIs
- branch, tag: use porcelain output
- ref-filter: allow porcelain to translate messages in the output
- ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames
- ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
- ref-filter: Do not abruptly die when using the 'lstrip=<N>' option
- ref-filter: rename the 'strip' option to 'lstrip'
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce refname_atom_parser()
- ref-filter: introduce refname_atom_parser_internal()
- ref-filter: make "%(symref)" atom work with the ':short' modifier
- ref-filter: add support for %(upstream:track,nobracket)
- ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
- ref-filter: introduce format_ref_array_item()
- ref-filter: move get_head_description() from branch.c
- ref-filter: modify "%(objectname:short)" to take length
- ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
- ref-filter: include reference to 'used_atom' within 'atom_value'
- ref-filter: implement %(if), %(then), and %(else) atoms
The code to list branches in "git branch" has been consolidated
with the more generic ref-filter API.
I think this is almost ready. Will wait for a few days, squash
fixes in if needed and merge to 'next'.
* jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
(merged to 'next' on 2016-12-05 at 0c77e39cd5)
+ setup_git_env: avoid blind fall-back to ".git"
Originally merged to 'next' on 2016-10-26
This is the endgame of the topic to avoid blindly falling back to
".git" when the setup sequence said we are _not_ in Git repository.
A corner case that happens to work right now may be broken by a
call to die("BUG").
Will cook in 'next'.
* pb/bisect (2016-10-18) 27 commits
- bisect--helper: remove the dequote in bisect_start()
- bisect--helper: retire `--bisect-auto-next` subcommand
- bisect--helper: retire `--bisect-autostart` subcommand
- bisect--helper: retire `--bisect-write` subcommand
- bisect--helper: `bisect_replay` shell function in C
- bisect--helper: `bisect_log` shell function in C
- bisect--helper: retire `--write-terms` subcommand
- bisect--helper: retire `--check-expected-revs` subcommand
- bisect--helper: `bisect_state` & `bisect_head` shell function in C
- bisect--helper: `bisect_autostart` shell function in C
- bisect--helper: retire `--next-all` subcommand
- bisect--helper: retire `--bisect-clean-state` subcommand
- bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
- t6030: no cleanup with bad merge base
- bisect--helper: `bisect_start` shell function partially in C
- bisect--helper: `get_terms` & `bisect_terms` shell function in C
- bisect--helper: `bisect_next_check` & bisect_voc shell function in C
- bisect--helper: `check_and_set_terms` shell function in C
- bisect--helper: `bisect_write` shell function in C
- bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
- bisect--helper: `bisect_reset` shell function in C
- wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
- t6030: explicitly test for bisection cleanup
- bisect--helper: `bisect_clean_state` shell function in C
- bisect--helper: `write_terms` shell function in C
- bisect: rewrite `check_term_format` shell function in C
- bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
Move more parts of "git bisect" to C.
Expecting a reroll.
cf. <CAFZEwPPXPPHi8KiEGS9ggzNHDCGhuqMgH9Z8-Pf9GLshg8+LPA@mail.gmail.com>
cf. <CAFZEwPM9RSTGN54dzaw9gO9iZmsYjJ_d1SjUD4EzSDDbmh-XuA@mail.gmail.com>
* st/verify-tag (2017-01-18) 6 commits
- t/t7004-tag: Add --format specifier tests
- t/t7030-verify-tag: Add --format specifier tests
- builtin/tag: add --format argument for tag -v
- builtin/verify-tag: add --format to verify-tag
- ref-filter: add function to print single ref_array_item
- gpg-interface, tag: add GPG_VERIFY_OMIT_STATUS flag
"git tag" and "git verify-tag" learned to put GPG verification
status in their "--format=<placeholders>" output format.
Will merge to 'next'.
* sg/fix-versioncmp-with-common-suffix (2017-01-12) 8 commits
(merged to 'next' on 2017-01-18 at f79c24a291)
+ versioncmp: generalize version sort suffix reordering
+ versioncmp: factor out helper for suffix matching
+ versioncmp: use earliest-longest contained suffix to determine sorting order
+ versioncmp: cope with common part overlapping with prerelease suffix
+ versioncmp: pass full tagnames to swap_prereleases()
+ t7004-tag: add version sort tests to show prerelease reordering issues
+ t7004-tag: use test_config helper
+ t7004-tag: delete unnecessary tags with test_when_finished
The prereleaseSuffix feature of version comparison that is used in
"git tag -l" did not correctly when two or more prereleases for the
same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2
are there and the code needs to compare 2.0-beta1 and 2.0-beta2).
Will merge to 'master'.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2016-12-05 at 041946dae0)
+ merge: drop 'git merge <message> HEAD <commit>' syntax
Originally merged to 'next' on 2016-10-11
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
Will cook in 'next'.
--------------------------------------------------
[Discarded]
* jc/bundle (2016-03-03) 6 commits
. index-pack: --clone-bundle option
. Merge branch 'jc/index-pack' into jc/bundle
. bundle v3: the beginning
. bundle: keep a copy of bundle file name in the in-core bundle header
. bundle: plug resource leak
. bundle doc: 'verify' is not about verifying the bundle
The beginning of "split bundle", which could be one of the
ingredients to allow "git clone" traffic off of the core server
network to CDN.
While I think it would make it easier for people to experiment and
build on if the topic is merged to 'next', I am at the same time a
bit reluctant to merge an unproven new topic that introduces a new
file format, which we may end up having to support til the end of
time. It is likely that to support a "prime clone from CDN", it
would need a lot more than just "these are the heads and the pack
data is over there", so this may not be sufficient.
* jk/nofollow-attr-ignore (2016-11-02) 5 commits
. exclude: do not respect symlinks for in-tree .gitignore
. attr: do not respect symlinks for in-tree .gitattributes
. exclude: convert "check_index" into a flags field
. attr: convert "macro_ok" into a flags field
. add open_nofollow() helper
As we do not follow symbolic links when reading control files like
.gitignore and .gitattributes from the index, match the behaviour
and not follow symbolic links when reading them from the working
tree. This also tightens security a bit by not leaking contents of
an unrelated file in the error messages when it is pointed at by
one of these files that is a symbolic link.
Perhaps we want to cover .gitmodules too with the same mechanism?
^ permalink raw reply
* Re: [RFC for GIT] pull-request: add praise to people doing QA
From: Jacob Keller @ 2017-01-19 23:42 UTC (permalink / raw)
To: Jeff King
Cc: Wolfram Sang, Junio C Hamano, Git mailing list,
linux-kernel@vger.kernel.org
In-Reply-To: <20170119212039.3gixsrk7qco45wjo@sigill.intra.peff.net>
On Thu, Jan 19, 2017 at 1:20 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Jan 19, 2017 at 09:43:45PM +0100, Wolfram Sang wrote:
>
>> > As to the implementation, I am wondering if we can make this somehow
>> > work well with the "trailers" code we already have, instead of
>> > inventing yet another parser of trailers.
>> >
>> > In its current shape, "interpret-trailers" focuses on "editing" an
>> > existing commit log message to tweak the trailer lines. That mode
>> > of operation would help amending and rebasing, and to do that it
>> > needs to parse the commit log message, identify trailer blocks,
>> > parse out each trailer lines, etc.
>> >
>> > There is no fundamental reason why its output must be an edited
>> > original commit log message---it should be usable as a filter that
>> > picks trailer lines of the selected trailer type, like "Tested-By",
>> > etc.
>>
>> I didn't know about trailers before. As I undestand it, I could use
>> "Tested-by" as the key, and the commit subject as the value. This list
>> then could be parsed and brought into proper output shape. It would
>> simplify the subject parsing, but most things my AWK script currently
>> does would still need to stay or to be reimplemented (extracting names
>> from tags, creating arrays of tags given by $name). Am I correct?
>>
>> All under the assumption that trailers work on a range of commits. I
>> have to admit that adding this to git is beyond my scope.
>
> This sounds a lot like the shortlog-trailers work I did about a year
> ago:
>
> http://public-inbox.org/git/20151229073832.GN8842@sigill.intra.peff.net/
>
> http://public-inbox.org/git/20151229075013.GA9191@sigill.intra.peff.net/
>
> Nobody seemed to really find it useful, so I didn't pursue it.
>
> Some of the preparatory patches in that series bit-rotted in the
> meantime, but you can play with a version based on v2.7.0 by fetching
> the "shortlog-trailers-historical" branch from
> https://github.com/peff/git.git.
>
> And then things like:
>
> git shortlog --ident=tested-by --format='...tested a patch by %an'
>
> work (and you can put whatever commit items you want into the --format,
> including just dumping the hash if you want to do more analysis).
>
> -Peff
This sounds interesting to me! When I have some more time to take a
look at this i might see if I can revive it.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v4 2/5] name-rev: extend --refs to accept multiple patterns
From: Jacob Keller @ 2017-01-19 23:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jacob Keller, Git mailing list, Johannes Sixt,
Johannes Schindelin
In-Reply-To: <xmqqfukezrmh.fsf@gitster.mtv.corp.google.com>
On Thu, Jan 19, 2017 at 1:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jacob Keller <jacob.e.keller@intel.com> writes:
>
>> From: Jacob Keller <jacob.keller@gmail.com>
>>
>> Teach git name-rev to take multiple --refs stored as a string list of
>> patterns. The list of patterns will be matched inclusively, and each ref
>> only needs to match one pattern to be included. A ref will only be
>> excluded if it does not match any of the given patterns. Additionally,
>> if any of the patterns would allow abbreviation, then we will abbreviate
>> the ref, even if another pattern is more strict and would not have
>> allowed abbreviation on its own.
>>
>> Add tests and documentation for this change. The tests expected output
>> is dynamically generated, but this is in order to avoid hard-coding
>> a commit object id in the test results (as the expected output is to
>> simply leave the commit object unnamed).
>
> Makes sense.
>
> I do not see anything that requires "... generated, but" there,
> though, as if it is a bad thing to do to prepare expected output
> dynamically. I'd just reword "generated. This is..." to make it
> neutral.
To clarify my earlier comment, I think the SQUASH?? you queued looks great.
Thanks,
Jake
^ permalink raw reply
* Post-merge hook
From: Ilesh Mistry @ 2017-01-19 23:54 UTC (permalink / raw)
To: git@vger.kernel.org
Hello
I have been looking around for this, but I can't seem to find any examples of how to use the git post-merge hook. Can you help me please?
I want to do something really simple in the sense of pulling locally and once pulled and merged any conflicts (if any) then run a command line code. But run this code after any merge conflicts are resolved.
Can you help me by pointing me into the right direction on how I can resolve this please?
Thanks
Ilesh
Sent from my iPhone
Ilesh Mistry
Kentico Technical Architect
T 01572 822 278
www.mmtdigital.co.uk <http://www.mmtdigital.co.uk>
RAR Digital Awards Winner 2016: Best Web Development Agency in the UK
RAR Digital Awards Winner 2016: Best Software Development Agency in the UK
RAR Digital Awards Winner 2016: Best Analytics Agency in the UK
RAR Digital Awards Winner 2015: Best Web Design Agency in the UK
Econsultancy 2016 Top 100 Agency
The Drum Digital Census 2015: Elite Agency Top 10
Participation in this email correspondence denotes acceptance of
terms and conditions available on request or from our website,
unless a separate contract has been agreed.
Registered Office: 1A Uppingham Gate, Ayston Road, Uppingham, Rutland, LE15 9NY
Company Number: 3681297
VAT Registration: 638 5654 05
^ permalink raw reply
* Re: [RFC for GIT] pull-request: add praise to people doing QA
From: Joe Perches @ 2017-01-20 0:06 UTC (permalink / raw)
To: Jacob Keller, Jeff King
Cc: Wolfram Sang, Junio C Hamano, Git mailing list,
linux-kernel@vger.kernel.org
In-Reply-To: <CA+P7+xo5N66a8-PeNRLBgwRN3rJZRbQuDnx8wCnW7L-0tz10Fg@mail.gmail.com>
On Thu, 2017-01-19 at 15:42 -0800, Jacob Keller wrote:
> On Thu, Jan 19, 2017 at 1:20 PM, Jeff King <peff@peff.net> wrote:
> > On Thu, Jan 19, 2017 at 09:43:45PM +0100, Wolfram Sang wrote:
> >
> > > > As to the implementation, I am wondering if we can make this somehow
> > > > work well with the "trailers" code we already have, instead of
> > > > inventing yet another parser of trailers.
> > > >
> > > > In its current shape, "interpret-trailers" focuses on "editing" an
> > > > existing commit log message to tweak the trailer lines. That mode
> > > > of operation would help amending and rebasing, and to do that it
> > > > needs to parse the commit log message, identify trailer blocks,
> > > > parse out each trailer lines, etc.
> > > >
> > > > There is no fundamental reason why its output must be an edited
> > > > original commit log message---it should be usable as a filter that
> > > > picks trailer lines of the selected trailer type, like "Tested-By",
> > > > etc.
> > >
> > > I didn't know about trailers before. As I undestand it, I could use
> > > "Tested-by" as the key, and the commit subject as the value. This list
> > > then could be parsed and brought into proper output shape. It would
> > > simplify the subject parsing, but most things my AWK script currently
> > > does would still need to stay or to be reimplemented (extracting names
> > > from tags, creating arrays of tags given by $name). Am I correct?
> > >
> > > All under the assumption that trailers work on a range of commits. I
> > > have to admit that adding this to git is beyond my scope.
> >
> > This sounds a lot like the shortlog-trailers work I did about a year
> > ago:
> >
> > http://public-inbox.org/git/20151229073832.GN8842@sigill.intra.peff.net/
> >
> > http://public-inbox.org/git/20151229075013.GA9191@sigill.intra.peff.net/
> >
> > Nobody seemed to really find it useful, so I didn't pursue it.
> >
> > Some of the preparatory patches in that series bit-rotted in the
> > meantime, but you can play with a version based on v2.7.0 by fetching
> > the "shortlog-trailers-historical" branch from
> > https://github.com/peff/git.git.
> >
> > And then things like:
> >
> > git shortlog --ident=tested-by --format='...tested a patch by %an'
> >
> > work (and you can put whatever commit items you want into the --format,
> > including just dumping the hash if you want to do more analysis).
> >
> > -Peff
>
> This sounds interesting to me! When I have some more time to take a
> look at this i might see if I can revive it.
Can the terminology please be standardized to what
was once called bylines?
https://patchwork.kernel.org/patch/9307703/
^ permalink raw reply
* Re: [RFC for GIT] pull-request: add praise to people doing QA
From: Jacob Keller @ 2017-01-20 0:13 UTC (permalink / raw)
To: Joe Perches
Cc: Jeff King, Wolfram Sang, Junio C Hamano, Git mailing list,
linux-kernel@vger.kernel.org
In-Reply-To: <1484870777.2707.2.camel@perches.com>
On Thu, Jan 19, 2017 at 4:06 PM, Joe Perches <joe@perches.com>
wrote:>> This sounds interesting to me! When I have some more time to
take a
>> look at this i might see if I can revive it.
>
> Can the terminology please be standardized to what
> was once called bylines?
>
> https://patchwork.kernel.org/patch/9307703/
>
I am fairly certain we've settled on "trailers" at this point. I don't
have an objection to either name, but most of the code today uses
trailers.
Thanks,
Jake
^ permalink raw reply
* [PATCH] git-prompt.sh: add submodule indicator
From: Benjamin Fuchs @ 2017-01-20 0:07 UTC (permalink / raw)
To: git; +Cc: szeder.dev, felipe.contreras, ville.skytta, email
I expirienced that working with submodules can be confusing. This indicator
will make you notice very easy when you switch into a submodule.
The new prompt will look like this: (sub:master)
Adding a new optional env variable for the new feature.
Signed-off-by: Benjamin Fuchs <email@benjaminfuchs.de>
---
contrib/completion/git-prompt.sh | 37 ++++++++++++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 97eacd7..4c82e7f 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -93,6 +93,10 @@
# directory is set up to be ignored by git, then set
# GIT_PS1_HIDE_IF_PWD_IGNORED to a nonempty value. Override this on the
# repository level by setting bash.hideIfPwdIgnored to "false".
+#
+# If you would like __git_ps1 to indicate that you are in a submodule,
+# set GIT_PS1_SHOWSUBMODULE. In this case a "sub:" will be added before
+# the branch name.
# check whether printf supports -v
__git_printf_supports_v=
@@ -284,6 +288,32 @@ __git_eread ()
test -r "$f" && read "$@" <"$f"
}
+# __git_is_submodule
+# Based on:
+# http://stackoverflow.com/questions/7359204/git-command-line-know-if-in-submodule
+__git_is_submodule ()
+{
+ local git_dir parent_git module_name path
+ # Find the root of this git repo, then check if its parent dir is also a repo
+ git_dir="$(git rev-parse --show-toplevel)"
+ module_name="$(basename "$git_dir")"
+ parent_git="$(cd "$git_dir/.." && git rev-parse --show-toplevel 2> /dev/null)"
+ if [[ -n $parent_git ]]; then
+ # List all the submodule paths for the parent repo
+ while read path
+ do
+ if [[ "$path" != "$module_name" ]]; then continue; fi
+ if [[ -d "$git_dir/../$path" ]]; then return 0; fi
+ done < <(cd $parent_git && git submodule --quiet foreach 'echo $path' 2> /dev/null)
+ fi
+ return 1
+}
+
+__git_ps1_submodule ()
+{
+ __git_is_submodule && printf "sub:"
+}
+
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
# when called from PS1 using command substitution
# in this mode it prints text to add to bash PS1 prompt (includes branch name)
@@ -513,8 +543,13 @@ __git_ps1 ()
b="\${__git_ps1_branch_name}"
fi
+ local sub=""
+ if [ -n "${GIT_PS1_SHOWSUBMODULE}" ]; then
+ sub="$(__git_ps1_submodule)"
+ fi
+
local f="$w$i$s$u"
- local gitstring="$c$b${f:+$z$f}$r$p"
+ local gitstring="$c$sub$b${f:+$z$f}$r$p"
if [ $pcmode = yes ]; then
if [ "${__git_printf_supports_v-}" != yes ]; then
--
2.7.4
^ permalink raw reply related
* Re: Git: new feature suggestion
From: Linus Torvalds @ 2017-01-20 0:26 UTC (permalink / raw)
To: Jakub Narębski
Cc: Konstantin Khomoutov, Joao Pinto, Git Mailing List,
CARLOS.PALMINHA@synopsys.com
In-Reply-To: <b96b71b9-f8a2-d039-6e8a-c64e7aac02a0@gmail.com>
On Thu, Jan 19, 2017 at 1:48 PM, Jakub Narębski <jnareb@gmail.com> wrote:
> W dniu 19.01.2017 o 19:39, Linus Torvalds pisze:
>>
>> You can do it in tig, but I suspect a more graphical tool might be better.
>
> Well, we do have "git gui blame".
Does that actually work for people? Because it really doesn't for me.
And I'm not just talking about the aesthetics of the thing, but the
whole experience, and the whole "dig into parent" which just gives me
an error message.
Linus
^ permalink raw reply
* Re: [PATCH] git-prompt.sh: add submodule indicator
From: Stefan Beller @ 2017-01-20 0:28 UTC (permalink / raw)
To: Benjamin Fuchs
Cc: git@vger.kernel.org, szeder.dev, felipe.contreras, ville.skytta
In-Reply-To: <1484870858-6336-1-git-send-email-email@benjaminfuchs.de>
On Thu, Jan 19, 2017 at 4:07 PM, Benjamin Fuchs <email@benjaminfuchs.de> wrote:
> I expirienced that working with submodules can be confusing. This indicator
> will make you notice very easy when you switch into a submodule.
> The new prompt will look like this: (sub:master)
> Adding a new optional env variable for the new feature.
>
> Signed-off-by: Benjamin Fuchs <email@benjaminfuchs.de>
Thanks for making submodules better :)
Relevant tangent, just posted today:
https://public-inbox.org/git/20170119193023.26837-1-sbeller@google.com/T/#u
> ---
> contrib/completion/git-prompt.sh | 37 ++++++++++++++++++++++++++++++++++++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> index 97eacd7..4c82e7f 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -93,6 +93,10 @@
> # directory is set up to be ignored by git, then set
> # GIT_PS1_HIDE_IF_PWD_IGNORED to a nonempty value. Override this on the
> # repository level by setting bash.hideIfPwdIgnored to "false".
> +#
> +# If you would like __git_ps1 to indicate that you are in a submodule,
> +# set GIT_PS1_SHOWSUBMODULE. In this case a "sub:" will be added before
> +# the branch name.
>
> # check whether printf supports -v
> __git_printf_supports_v=
> @@ -284,6 +288,32 @@ __git_eread ()
> test -r "$f" && read "$@" <"$f"
> }
>
> +# __git_is_submodule
> +# Based on:
> +# http://stackoverflow.com/questions/7359204/git-command-line-know-if-in-submodule
> +__git_is_submodule ()
> +{
> + local git_dir parent_git module_name path
> + # Find the root of this git repo, then check if its parent dir is also a repo
> + git_dir="$(git rev-parse --show-toplevel)"
> + module_name="$(basename "$git_dir")"
> + parent_git="$(cd "$git_dir/.." && git rev-parse --show-toplevel 2> /dev/null)"
I wonder if we want to have better plumbing commands for submodules
here as well:
Here we only check if we have an embedded git repository, which may not be a
submodule. It could be a standalone repo that just happens to be inside another.
It could be a fake submodule [1], though I think the last time I
brought these up,
the upstream Git community considered these fake submodules are bug not worth
fixing.
And this doesn't cover the case that I addressed in the RFC-ish patch above:
$ git submodule deinit --all
$ cd <submodule> && git status
# in an ideal world this tells you:
# "You are in an un-populated submodule. To change the submodule state..."
So I guess this is a good first approximation that actually gets most
of the cases right,
thereby helping a lot of people. But I wonder about these cornercases as well?
[1] debuggable.com/posts/git-fake-submodules:4b563ee4-f3cc-4061-967e-0e48cbdd56cb
Thanks,
Stefan
^ permalink raw reply
* Re: submodule network operations [WAS: Re: [RFC/PATCH 0/4] working tree operations: support superprefix]
From: Stefan Beller @ 2017-01-20 1:22 UTC (permalink / raw)
To: Brian J. Davis; +Cc: Brandon Williams, git@vger.kernel.org, David Turner
In-Reply-To: <e6c5567a-2032-c598-97c8-08518f86b611@gmail.com>
>> Between the init and the update step you can modify the URLs.
>> These commands are just a repetition from the first email, but the
>> git commands can be viewed as moving from one state to another
>> for submodules; submodules itself can be seen as a state machine
>> according to that proposed documentation. Maybe such a state machine
>> makes it easier to understand for some people.
>
>
> "Between the init and the update step you can modify the URLs." Yes I can
> and have to... wish it was not this way.
So how would yo u rather want to do it?
look at the .gitmodules file beforehand and then run a "submodule update" ?
Or a thing like
git -c url.https://internal.insteadOf git://github.com/ \
-c submodule.record-rewritten-urls submodule update
(no need for init there as theoretically there is not
need for such an intermediate step)
>> [remote "origin"]
>> url = https://github.com/..
>> [remote "inhouse"]
>> url = https://inhouse.corp/..
>>
>> But where do we clone it from?
>> (Or do we just do a "git init" on that submodule and fetch
>> from both remotes? in which order?)
>
> origin by default and inhouse if specified. There is already a implied
> default (origin). The idea was not to do both but rather what is specified.
> Origin and inhouse are just names for remotes. If one wanted a
> "--all-remotes" could pull from everywhere in the Ether if feature was to be
> implemented.
How is origin implied to be the default?
Should there be an order (e.g. if you cannot find it at inhouse get it
from github,
if they are down, get it from kernel.org)
^ permalink raw reply
* [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard
From: Nguyễn Thái Ngọc Duy @ 2017-01-20 10:22 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
OK This patch is horrible. Though the idea is cool and I've found it
very useful. So here it is. Perhaps the idea may be revised a bit
that's more suitable for more than one user.
The problem is old, SHA-1 name is not keyboard-friendly, even in
abbreviated form. And recent change has made abbrev form longer,
harder to type. Most of the time I just go with copy/paste with the
mouse, which I don't like. name-rev helps a bit, but it's still long
to type (especially with all the ^ and ~ that requires holding shift
down).
So, this patch adds an option --mark-commits to git-log. Whenever a
commit SHA-1 is printed on screen, it gets a new shortcut in form of
<at-sign><one-letter><number> e.g. @h2. The number keeps increasing
during one git-log, so you'll get @h1, @h2, @h3 and so on. Typing @h3
gets you back to the associated SHA-1.
Different git-log runs will change the <one-letter> part. So the
second git-log run may give you @j1, @j2, @j3... This is useful
because sometimes you want to run more than one command, then
reference back to commits from the first command.
There's a limited number of letters to be used here. I limit it to the
letters on the home row to avoid moving fingers too much. Which means
after like 9 runs, @h is recycled for something new. Not great if you
have "git blah blah @h2" in bash history and keep recalling it from
time to time.
So, whenever you use a shortcut, the shortcut is kept in a "database"
and will not be recycled for quite some time. When @h is recycled,
you'll get @h1, then @h3 and so on if @h2 has just been used recently.
This makes sure recently used shortcuts live on.
That's it. I have to say typing 3-4 characters is really nice. I kinda
want to reduce the number of keystokes further down, but it's been good
enough that I'm not so pissed to spend time tuning it further.
This shortcut format violates the extended sha1 syntax, I think. In
order have any chance of entering git, we'll have to deal with that
first.
---
Makefile | 1 +
commit.h | 1 +
log-tree.c | 7 +++
pretty.c | 5 ++
rev-counter.c (new) | 166 ++++++++++++++++++++++++++++++++++++++++++++++++++++
rev-counter.h (new) | 10 ++++
revision.c | 4 ++
revision.h | 1 +
sha1_name.c | 8 +++
9 files changed, 203 insertions(+)
create mode 100644 rev-counter.c
create mode 100644 rev-counter.h
diff --git a/Makefile b/Makefile
index de5a030256..28948bd9eb 100644
--- a/Makefile
+++ b/Makefile
@@ -788,6 +788,7 @@ LIB_OBJS += replace_object.o
LIB_OBJS += rerere.o
LIB_OBJS += resolve-undo.o
LIB_OBJS += revision.o
+LIB_OBJS += rev-counter.o
LIB_OBJS += run-command.o
LIB_OBJS += send-pack.o
LIB_OBJS += sequencer.o
diff --git a/commit.h b/commit.h
index b06db4d5d9..8f67687208 100644
--- a/commit.h
+++ b/commit.h
@@ -155,6 +155,7 @@ struct pretty_print_context {
struct string_list *mailmap;
int color;
struct ident_split *from_ident;
+ int mark_commits;
/*
* Fields below here are manipulated internally by pp_* functions and
diff --git a/log-tree.c b/log-tree.c
index 78a5381d0e..f49366b376 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -11,6 +11,7 @@
#include "gpg-interface.h"
#include "sequencer.h"
#include "line-log.h"
+#include "rev-counter.h"
static struct decoration name_decoration = { "object names" };
static int decoration_loaded;
@@ -593,6 +594,9 @@ void show_log(struct rev_info *opt)
}
opt->shown_one = 1;
+ if (opt->mark_commits)
+ mark_commit(&commit->object.oid);
+
/*
* If the history graph was requested,
* print the graph, up to this commit's line
@@ -615,6 +619,8 @@ void show_log(struct rev_info *opt)
put_revision_mark(opt, commit);
fputs(find_unique_abbrev(commit->object.oid.hash, abbrev_commit),
stdout);
+ if (opt->mark_commits)
+ printf(" @%s", oid_to_commit_mark(&commit->object.oid));
if (opt->print_parents)
show_parents(commit, abbrev_commit);
if (opt->children.name)
@@ -687,6 +693,7 @@ void show_log(struct rev_info *opt)
ctx.output_encoding = get_log_output_encoding();
if (opt->from_ident.mail_begin && opt->from_ident.name_begin)
ctx.from_ident = &opt->from_ident;
+ ctx.mark_commits = opt->mark_commits;
pretty_print_commit(&ctx, commit, &msgbuf);
if (opt->add_signoff)
diff --git a/pretty.c b/pretty.c
index c3ec430220..14e0022085 100644
--- a/pretty.c
+++ b/pretty.c
@@ -10,6 +10,7 @@
#include "color.h"
#include "reflog-walk.h"
#include "gpg-interface.h"
+#include "rev-counter.h"
static char *user_format;
static struct cmt_fmt_map {
@@ -1127,6 +1128,8 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
case 'H': /* commit hash */
strbuf_addstr(sb, diff_get_color(c->auto_color, DIFF_COMMIT));
strbuf_addstr(sb, oid_to_hex(&commit->object.oid));
+ if (c->pretty_ctx->mark_commits)
+ strbuf_addf(sb, " @%s", oid_to_commit_mark(&commit->object.oid));
strbuf_addstr(sb, diff_get_color(c->auto_color, DIFF_RESET));
return 1;
case 'h': /* abbreviated commit hash */
@@ -1137,6 +1140,8 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
}
strbuf_addstr(sb, find_unique_abbrev(commit->object.oid.hash,
c->pretty_ctx->abbrev));
+ if (c->pretty_ctx->mark_commits)
+ strbuf_addf(sb, " @%s", oid_to_commit_mark(&commit->object.oid));
strbuf_addstr(sb, diff_get_color(c->auto_color, DIFF_RESET));
c->abbrev_commit_hash.len = sb->len - c->abbrev_commit_hash.off;
return 1;
diff --git a/rev-counter.c b/rev-counter.c
new file mode 100644
index 0000000000..60ab991fe1
--- /dev/null
+++ b/rev-counter.c
@@ -0,0 +1,166 @@
+#include "cache.h"
+#include "strbuf.h"
+#include "commit.h"
+#include "commit-slab.h"
+
+define_commit_slab(counter, char *);
+struct counter counter = COMMIT_SLAB_INIT(1, counter);
+
+static unsigned commit_counter;
+static int run_counter;
+int latest_fd = -1;
+struct strbuf recent = STRBUF_INIT;
+
+/* home row, except 'l' which looks too much like '1' */
+const char *starter = "asdfghjk";
+
+static void start_marking(void)
+{
+ char buf[64];
+ ssize_t len;
+
+ len = readlink(git_path("rev-counter/latest"), buf, sizeof(buf));
+ if (len == -1) {
+ if (errno != ENOENT)
+ die_errno("failed to open rev-counter/latest");
+ } else {
+ char ch, *p;
+ sscanf(buf, "%c", &ch);
+ p = strchrnul(starter, ch);
+ run_counter = ((p - starter) + 1) % strlen(starter);
+ }
+
+ if (!is_directory(git_path("rev-counter")))
+ mkdir(git_path("rev-counter"), 0755);
+ latest_fd = open(git_path("rev-counter/%c", starter[run_counter]),
+ O_RDWR | O_CREAT | O_TRUNC, 0644);
+ if (latest_fd == -1)
+ die_errno("failed to create new rev-counter");
+
+ sprintf(buf, "%c", starter[run_counter]);
+ (void)unlink(git_path("rev-counter/latest"));
+ if (symlink(buf, git_path("rev-counter/latest")))
+ die_errno("failed to update rev-counter/latest");
+}
+
+static int strbuf_find_commit_mark(const struct strbuf *sb,
+ const char *mark,
+ struct object_id *oid)
+{
+ const char *p, *end;
+ int ret = -1;
+
+ end = sb->buf + sb->len;
+ p = sb->buf;
+ while (p < end && ret < 0) {
+ const char *next = strchrnul(p, '\n');
+
+ if (next - p > 41 &&
+ p[40] == ' ' &&
+ p + 41 + strlen(mark) == next &&
+ !strncmp(p + 41, mark, strlen(mark)) &&
+ !get_oid_hex(p, oid))
+ ret = 0;
+
+ p = next;
+ if (*p == '\n')
+ p++;
+ }
+ return ret;
+}
+
+void update_commit_counter(void)
+{
+ static int read_recent;
+ struct object_id oid;
+ char buf[16];
+
+ if (!read_recent) {
+ strbuf_read_file(&recent, git_path("rev-counter/recent"), 0);
+ read_recent = 1;
+
+ if (recent.len > 1000 * 45) { /* prune time? */
+ int fd;
+ const char *p = strchr(recent.buf + 1000 * 45, '\n');
+ strbuf_remove(&recent, 0, p + 1 - recent.buf);
+ if (!is_directory(git_path("rev-counter")))
+ mkdir(git_path("rev-counter"), 0755);
+ fd = open(git_path("rev-counter/recent"),
+ O_CREAT | O_TRUNC | O_RDWR, 0644);
+ write_or_die(fd, recent.buf, recent.len);
+ close(fd);
+ }
+ }
+
+ do {
+ commit_counter++;
+ sprintf(buf, "%c%u", starter[run_counter], commit_counter);
+ } while (!strbuf_find_commit_mark(&recent, buf, &oid));
+}
+
+void mark_commit(const struct object_id *oid)
+{
+ struct commit *c;
+ char buf[64];
+ char **val;
+
+ if (latest_fd < 0)
+ start_marking();
+
+ if (!(c = lookup_commit(oid->hash)))
+ return;
+
+ update_commit_counter();
+ sprintf(buf, "%s %u\n", oid_to_hex(oid), commit_counter);
+ write_or_die(latest_fd, buf, strlen(buf));
+
+ sprintf(buf, "%c%u", starter[run_counter], commit_counter);
+ val = counter_at(&counter, c);
+ *val = xstrdup(buf);
+}
+
+const char *oid_to_commit_mark(const struct object_id *oid)
+{
+ struct commit *c;
+ char **val;
+
+ if (!(c = lookup_commit(oid->hash)) ||
+ !(val = counter_peek(&counter, c)))
+ return NULL;
+
+ return *val;
+}
+
+int commit_mark_to_oid(const char *mark, struct object_id *oid)
+{
+ char buf[16];
+ int ret, c;
+ char r_ch;
+ struct strbuf sb = STRBUF_INIT;
+
+ if (sscanf(mark, "%c%u", &r_ch, &c) != 2 ||
+ !strchr(starter, r_ch) ||
+ strbuf_read_file(&sb, git_path("rev-counter/%c", r_ch), 0) < 0)
+ return -1;
+
+ sprintf(buf, "%u", c);
+ ret = strbuf_find_commit_mark(&sb, buf, oid);
+ strbuf_release(&sb);
+
+ if (!ret) {
+ char line[80];
+ static int fd;
+
+ if (!fd) {
+ if (!is_directory(git_path("rev-counter")))
+ mkdir(git_path("rev-counter"), 0755);
+ fd = open(git_path("rev-counter/recent"),
+ O_CREAT | O_RDWR | O_APPEND, 0644);
+ if (fd == -1)
+ die("failed to open rev-counter/recent");
+ }
+ sprintf(line, "%s %s\n", oid_to_hex(oid), mark);
+ write_or_die(fd, line, strlen(line));
+ }
+ return ret;
+}
diff --git a/rev-counter.h b/rev-counter.h
new file mode 100644
index 0000000000..ab2e8d8803
--- /dev/null
+++ b/rev-counter.h
@@ -0,0 +1,10 @@
+#ifndef __REV_COUNTER_H__
+#define __REV_COUNTER_H__
+
+struct object_id;
+
+void mark_commit(const struct object_id *oid);
+const char *oid_to_commit_mark(const struct object_id *oid);
+int commit_mark_to_oid(const char *mark, struct object_id *oid);
+
+#endif
diff --git a/revision.c b/revision.c
index 2f60062876..1e32e91b9f 100644
--- a/revision.c
+++ b/revision.c
@@ -1998,6 +1998,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
revs->limited = 1;
} else if (!strcmp(arg, "--ignore-missing")) {
revs->ignore_missing = 1;
+ } else if (!strcmp(arg, "--mark-commits")) {
+ revs->mark_commits = 1;
+ } else if (!strcmp(arg, "--no-mark-commits")) {
+ revs->mark_commits = 0;
} else {
int opts = diff_opt_parse(&revs->diffopt, argv, argc, revs->prefix);
if (!opts)
diff --git a/revision.h b/revision.h
index 9fac1a607d..94e5b70ff5 100644
--- a/revision.h
+++ b/revision.h
@@ -146,6 +146,7 @@ struct rev_info {
unsigned int track_linear:1,
track_first_time:1,
linear:1;
+ unsigned int mark_commits:1;
struct date_mode date_mode;
int expand_tabs_in_log; /* unset if negative */
diff --git a/sha1_name.c b/sha1_name.c
index ca7ddd6f2c..d3e1ff3921 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -7,6 +7,7 @@
#include "refs.h"
#include "remote.h"
#include "dir.h"
+#include "rev-counter.h"
static int get_sha1_oneline(const char *, unsigned char *, struct commit_list *);
@@ -485,6 +486,13 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1,
}
return 0;
}
+ if (len > 2 && str[0] == '@' && isalpha(str[1]) && isdigit(str[2])) {
+ struct object_id oid;
+ if (!commit_mark_to_oid(str + 1, &oid)) {
+ hashcpy(sha1, oid.hash);
+ return 0;
+ }
+ }
/* basic@{time or number or -number} format to query ref-log */
reflog_len = at = 0;
--
2.11.0.157.gd943d85
^ permalink raw reply related
* Re: [PATCH v3 14/21] read-cache: touch shared index files when used
From: Duy Nguyen @ 2017-01-20 10:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, git, Ævar Arnfjörð Bjarmason,
Christian Couder
In-Reply-To: <xmqqlgu627uj.fsf@gitster.mtv.corp.google.com>
On Fri, Jan 20, 2017 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Mon, Jan 9, 2017 at 9:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Duy Nguyen <pclouds@gmail.com> writes:
>>>
>>>> On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>> Christian Couder <christian.couder@gmail.com> writes:
>>>>>
>>>>>> So what should we do if freshen_file() returns 0 which means that the
>>>>>> freshening failed?
>>>>>
>>>>> You tell me ;-) as you are the one who is proposing this feature.
>>>>
>>>> My answer is, we are not worse than freshening loose objects case
>>>> (especially since I took the idea from there).
>>>
>>> I do not think so, unfortunately. Loose object files with stale
>>> timestamps are not removed as long as objects are still reachable.
>>
>> But there are plenty of unreachable loose objects, added in index,
>> then got replaced with new versions. cache-tree can create loose trees
>> too and it's been run more often, behind user's back, to take
>> advantage of the shortcut in unpack-trees.
>
> I am not sure if I follow. Aren't objects reachable from the
> cache-tree in the index protected from gc?
I think the problem is loose objects created then gc run just before
they are referenced (e.g. index written down). But I think I may be
following a wrong road. If mtime is in fact to deal with race
conditions, applying the same idea here is wrong because we have a
different problem here.
> Not that I think freshening would actually fail in a repository
> where you can actually write into to update the index or its refs to
> make a difference (iow, even if we make it die() loudly when shared
> index cannot be "touched" because we are paranoid, no real life
> usage will trigger that die(), and if a repository does trigger the
> die(), I think you would really want to know about it).
--
Duy
^ permalink raw reply
* Re: [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard
From: Johannes Schindelin @ 2017-01-20 10:46 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20170120102249.15572-1-pclouds@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]
Hi Duy,
On Fri, 20 Jan 2017, Nguyễn Thái Ngọc Duy wrote:
> OK This patch is horrible.
Yeah ;-)
> Though the idea is cool and I've found it very useful. So here it is.
> Perhaps the idea may be revised a bit that's more suitable for more than
> one user.
Why not introduce a flag to "git log" that shows a keyboard-friendly name
similar to what `git name-rev` would have said, except that the name would
be generated using the name(s) specified on the command-line?
Example:
git log 8923d2d0 upstream/pu
commit 8923d2d00192ceb1107078484cccf537cb51c1b5 (8923d2d0)
...
commit 9f500d6cf5eaa49391d6deca85fc864e5bd23415 (8923d2d0^)
...
commit f79c24a291a58845b08cfec7573e22cc153693e1 (8923d2d0~2)
...
commit c921c5bb63baaa16dc760de9549da55c8c89dc9c (upstream/pu)
...
commit 16793ba6b6333ba0cdee1adb53d979c3fbdb17bc (upstream/pu^)
...
Granted, this is still a little more cumbersome to type than @h1, but
then, you can skip those round-robin games as well as the possibly
backwards-incompatible extension of the rev syntax.
Ciao,
Johannes
^ permalink raw reply
* Re: Git: new feature suggestion
From: Joao Pinto @ 2017-01-20 10:44 UTC (permalink / raw)
To: Stefan Beller, Joao Pinto
Cc: Linus Torvalds, Konstantin Khomoutov, Git Mailing List,
CARLOS.PALMINHA@synopsys.com
In-Reply-To: <CAGZ79kZ3g+J5=ZmP8zDCK8zBwMc7SwLdmgyB3Sab8qkTE=enhQ@mail.gmail.com>
Hi Stefan,
Às 10:03 PM de 1/19/2017, Stefan Beller escreveu:
> On Thu, Jan 19, 2017 at 1:51 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>> Às 7:16 PM de 1/19/2017, Linus Torvalds escreveu:
>>> On Thu, Jan 19, 2017 at 10:54 AM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>>
>>>> I am currently facing some challenges in one of Linux subsystems where a rename
>>>> of a set of folders and files would be the perfect scenario for future
>>>> development, but the suggestion is not accepted, not because it's not correct,
>>>> but because it makes the maintainer life harder in backporting bug fixes and new
>>>> features to older kernel versions and because it is not easy to follow the
>>>> renamed file/folder history from the kernel.org history logs.
>>>
>>> Honestly, that's less of a git issue, and more of a "patch will not
>>> apply across versions" issue.
>>>
>>> No amount of rename detection will ever fix that, simply because the
>>> rename hadn't even _happened_ in the old versions that things get
>>> backported to.
>>>
>>> ("git cherry-pick" can do a merge resolution and thus do "backwards"
>>> renaming too, so tooling can definitely help, but it still ends up
>>> meaning that even trivial patches are no longer the _same_ trivial
>>> patch across versions).
>>>
>>> So renaming things increases maintainer workloads in those situations
>>> regardless of any tooling issues.
>>>
>>> (You may also be referring to the mellanox mess, where this issue is
>>> very much exacerbated by having different groups working on the same
>>> thing, and maintainers having very much a "I will not take _anything_
>>> from any of the groups that makes my life more complicated" model,
>>> because those groups fucked up so much in the past).
>>>
>>> In other words, quite often issues are about workflows rather than
>>> tools. The networking layer probably has more of this, because David
>>> actually does the backports himself, so he _really_ doesn't want to
>>> complicate things.
>>
>> I totally understand David' side! Synopsys is a well-known IP Vendor, and for a
>> long time its focus was the IP only. Knowadays the strategy has changed and
>> Synopsys is very keen to help in Open Source, namelly Linux, developing the
>> drivers for new IP Cores and participating in the improvement of existing ones.
>> I am part of the team that has that job.
>>
>> In USB and PCI subystems developers created common Synopsys drivers (focused on
>> the HW IP) and so today they are massively used by all the SoC that use Synopsys
>> IP.
>>
>> In the network subsystem, there are some drivers that target the same IP but
>> were made by different companies. stmmac is an excelent driver for Synopsys MAC
>> 10/100/1000/QOS IPs, but there was another driver made by AXIS driver that also
>> targeted the QOS IP. We detected that issue and merged the AXIS specific driver
>> ops to stmmac, and nowadays, AXIS uses stmmac. So less drivers to maintain!
>>
>> The idea that was rejected consisted of renaming stmicro/stmmac to dwc/stmmac
>> and to have dwc (designware controllers) as the official driver spot for
>> Synopsys Ethernet IPs.
>> There is another example of duplication, which is AMD' and Samsung' XGMAC
>> driver, targeting the same Synopsys XGMAC IP.
>>
>> I am giving this examples because although the refactor adds work for
>> backporting, it reduces the maintenance since we would have less duplicated
>> drivers as we have today.
>
> This sounds as if the code in question would only receive backports
> for a specific
> time (determined by HW lifecycle, maintenance life cycle and such).
>
> So I wonder if this could be solved by not just renaming but
> additionally adding a
> symbolic link, such that the files in question seem to appear twice on
> the file system.
> Then backports ought to be applicable (hoping git-am doesn't choke on symlinks),
> and after a while once the there no backports any more (due to life
> cycle reasons),
> remove the link?
>
> This also sounds like a kind of problem, that others have run into before,
> how did they solve it?
I am currently involved in the PCI host/ refactor process and that will cause a
total reorganization of the folder, because a new PCIe Endpoint is comming up
from Texas Instruments. Bjorn (PCI Maintainer) is ok with it.
The network subsystem, is a very busy one, with lots of activity, and so I
understand David Miller' point, because he already has work overload, but we
have to find a way to improve it and prepare for the future.
I think this a hot topic, that should be discussed, since it might hold back the
evolution of some subystems.
Thanks,
Joao
>
> Thanks,
> Stefan
>
>>
>> Thanks,
>> Joao
>>
>>
>>> Linus
>>>
>>
^ permalink raw reply
* Re: [PATCH] log: new option decorate reflog of remote refs
From: Duy Nguyen @ 2017-01-20 10:55 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20170119172310.6meuj6ksxloeee2t@sigill.intra.peff.net>
On Fri, Jan 20, 2017 at 12:23 AM, Jeff King <peff@peff.net> wrote:
> I think it's a neat idea, but the actual option:
>
>> +--decorate-remote-reflog[=<n>]::
>> + Decorate `<n>` most recent reflog entries on remote refs, up
>> + to the specified number of entries. By default, only the most
>> + recent reflog entry is decorated.
>
> seems weirdly limited and non-orthogonal. What happens when somebody
> wants to decorate other reflogs besides refs/remotes?
>
> We already have very flexible ref-selectors like --remotes, --branches,
> etc. The generalization of this would perhaps be something like:
>
> git log --decorate-reflog --remotes --branches
>
> where "--decorate-reflog" applies to the next ref selector and then is
> reset, the same way --exclude is. And it includes those refs _only_ for
> decoration, not for traversal. So you could do:
>
> git log --decorate-reflog --remotes --remotes
>
> if you wanted to see use those as traversal roots, too (if this is
> common, it might even merit another option for "decorate and show").
>
> That's just off the top of my head, so maybe there are issues. I was
> just surprised to see the "-remote" part in your option name.
Imposing order between options could cause confusion, I think, if you
remove --decorate-reflog leaving --remotes on by accident, now you get
--remotes with a new meaning. We could go with something like
--decodate-reflog=remote, but that clashes with the number of reflog
entries and we may need a separator, like --decorate-reflog=remote,3.
Or we could add something to --decorate= in addition to
short|full|auto|no. Something like --decorate=full,reflog or
--decorate=full,reflog=remote,entries=3 if I want 3 reflog entries.
My hesitant to go that far is because I suspect decorating reflog
won't be helpful for non-remotes. But I'm willing to make more changes
if it opens door to master.
--
Duy
^ permalink raw reply
* Re: [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard
From: Duy Nguyen @ 2017-01-20 11:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.20.1701201138520.3469@virtualbox>
On Fri, Jan 20, 2017 at 5:46 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Why not introduce a flag to "git log" that shows a keyboard-friendly name
> similar to what `git name-rev` would have said, except that the name would
> be generated using the name(s) specified on the command-line?
>
> Example:
>
> git log 8923d2d0 upstream/pu
>
> commit 8923d2d00192ceb1107078484cccf537cb51c1b5 (8923d2d0)
> ...
> commit 9f500d6cf5eaa49391d6deca85fc864e5bd23415 (8923d2d0^)
> ...
> commit f79c24a291a58845b08cfec7573e22cc153693e1 (8923d2d0~2)
> ...
> commit c921c5bb63baaa16dc760de9549da55c8c89dc9c (upstream/pu)
> ...
> commit 16793ba6b6333ba0cdee1adb53d979c3fbdb17bc (upstream/pu^)
> ...
>
> Granted, this is still a little more cumbersome to type than @h1, but
> then, you can skip those round-robin games as well as the possibly
> backwards-incompatible extension of the rev syntax.
I mentioned name-rev a few paragraphs down. No, I want the sweet and
short @h1 (or something like that). name-rev does not qualify. I don't
feel comfortable typing 8923d2d0 without looking at the keyboard, and
that's a lot of movement on the keyboard. upstream/pu is a bit
better, but still very long (at least for me). Yes TAB-ing does help,
but not enough. Then you'll get the dreadful "^2~1^3" dance.
--
Duy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox