From: "Stefan Beller"
When a submodule is initialized, the config variable
'submodule..url'
is set depending on the value of the same variable in the .gitmodules
file. When the URL indicates to be relative, then the url is computed
relative to its default remote. The default remote cannot be de
From: "Andreas Heiduk"
[PATCH] Documentation: Clarify core.quotePath, remove cruft in
git-ls-files.
Signed-off-by: Andreas Heiduk
---
I have merged the best parts about quoting into the core.quotePath
description and cleaned up the text in git-ls-files.txt regarding the
control characters.
From: "Alex Hoffman"
isn't that spelt `--ancestry-path` ?
(--ancestry-path has it's own issues such as needing
an --first-parent-show
option, but that's possibly a by the by)
Indeed it is spelled `--ancestry-path`. And interestingly enough you
may use it multiple times with the wanted effect
From: "Jakub Narębski"
W dniu 20.02.2017 o 21:31, Alex Hoffman pisze:
I see two different problems each with a different assumption (see the
definition of "bisectable" in the email of Junio C Hamano):
1. (Current) Assume the entire history graph is bisectable. DO: Search
where in the entire gr
From: "Jeff King"
On Sun, Feb 19, 2017 at 12:20:33AM -0000, Philip Oakley wrote:
> Normalize 'refname' by removing any leading slash (`/`)
> characters and collapsing runs of adjacent slashes between
> - name components into a single slash. Iff the normaliz
From: "Damien Regad"
---
Documentation/git-check-ref-format.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-check-ref-format.txt
b/Documentation/git-check-ref-format.txt
index 8611a99..377c85a 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Docu
From: "Alex Hoffman"
But this is not how Git works. Git computes graph differences, i.e., it
subtracts from the commits reachable from v.bad those that are reachable
from v.good. This leaves more than just those on some path from v.good to
v.bad. And it should work this way. Consider this histor
From: "Junio C Hamano"
Sent: Thursday, February 16, 2017 12:20 AM
"Philip Oakley" writes:
It may even be worth 'splitting' the pu branch sequence into the
existing pu (with merges from series that are selected as reasonable),
and then a pr branch (public revie
From: "Grégoire PARIS"
> You could, for example, have your template directory itself be a git
repository.
I can and I do and indeed, that might be the reason behind this.
I made a PR to document this : https://github.com/git/git/pull/325
While the PR is a simple one line change to the document
From: "Johannes Schindelin"
Hi Philip,
On Tue, 14 Feb 2017, Philip Oakley wrote:
From: "Christian Couder"
> On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano
> wrote:
> > Johannes Schindelin writes:
> >
> > > On Mon, 13 Feb 2017, Junio C
[sorry for the repeated emails - I'd prepared it off line, and then suffered
a number of auto send actions]
From: "Junio C Hamano"
"Philip Oakley" writes:
In the next..pu case the abstraction is in the other direction, we
have potentially multiple points of infecti
From: "Junio C Hamano"
"Philip Oakley" writes:
There are also a few ideas at the SO answers:
http://stackoverflow.com/a/5652323/717355
I vaguely recall that I saw somebody said the same "mark tips of
topics as good" on the list and answered with why it do
From: "Junio C Hamano"
"Philip Oakley" writes:
There are also a few ideas at the SO answers:
http://stackoverflow.com/a/5652323/717355
I vaguely recall that I saw somebody said the same "mark tips of
topics as good" on the list and answered with why it do
From: "Junio C Hamano"
"Philip Oakley" writes:
There are also a few ideas at the SO answers:
http://stackoverflow.com/a/5652323/717355
I vaguely recall that I saw somebody said the same "mark tips of
topics as good" on the list and answered with why it does no
From: "Christian Couder"
On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano
wrote:
Johannes Schindelin writes:
On Mon, 13 Feb 2017, Junio C Hamano wrote:
Johannes Schindelin writes:
> That is why I taught the Git for Windows CI job that tests the four
> upstream Git integration branches t
Ping
Any comments anyone?
(https://public-inbox.org/git/20170122195301.1784-1-philipoak...@iee.org/)
I understand that the Git-for-Windows team is planning to include this in
their next release, so additional eyes are welcomed.
Philip
From: "Philip Oakley" date: Sunday, January 2
From: "Johannes Schindelin"
Hi Junio,
On Thu, 9 Feb 2017, Junio C Hamano wrote:
Johannes Schindelin writes:
> Almost. While I fixed the performance issues as well as the design
> allowed, I happened to "fix" the problem where an incomplete prefix
> match could be favored over an exact match
From: "Jeff King"
On Wed, Feb 08, 2017 at 09:02:22PM -0500, David Turner wrote:
The intent of automatic gc is to have a git repository be relatively
low-maintenance from a server-operator perspective. Of course, large
operators like GitHub will need a more complicated management strategy,
but
From: "Johannes Schindelin"
Sent: Thursday, February 09, 2017 8:55 PM
Hi Ashutosh and Junio,
On Wed, 8 Feb 2017, Junio C Hamano wrote:
Ashutosh Bapat writes:
> I have been using git rebase heavily these days and seem to have found
> a bug.
>
> If there are two commit messages which have sam
From: "Duy Nguyen"
On Sat, Feb 4, 2017 at 3:28 AM, Jacob Keller
wrote:
+
+$ git reset HEAD^ <1>
It may be a good idea to add -N here, so that 'add -p' can pick up the
new files if they are added in HEAD.
When looking at the man page for `reset` [1] it
From: "G. Sylvie Davies"
On Fri, Jan 27, 2017 at 9:51 AM, Jeff King wrote:
On Fri, Jan 27, 2017 at 11:56:08AM -0500, Michael Spiegel wrote:
I'm trying to determine whether a merge required a conflict to resolve
after the merge has occurred. The git book has some advice
(https://git-scm.com/b
impression that
pgp-signing could be relevant at later stages of the submission.
Signed-off-by: Cornelius Weig
Signed-off-by: Junio C Hamano
Signed-off-by: Philip Oakley
Signed-off-by: Stefan Beller
---
Notes:
This patch summarizes the suggested changes.
As I don't know what is appr
From: "Junio C Hamano"
Cornelius Weig writes:
How about something along these lines? Does the forward reference
break the main line of thought too severly?
I find it a bit distracting for those who know PGP signing has
nothing to do with signing off your patch, but I think that is OK
becaus
From: "Stefan Beller"
Do not PGP sign your patch, at least *for now*. (...)
And maybe these 2 small words are the bug in the documentation?
Shall we drop the "at least for now" part, like so:
---8<---
From 2c4fe0e67451892186ff6257b20c53e088c9ec67 Mon Sep 17 00:00:00 2001
From: Stefan Bell
From: "Jakub Narębski"
W dniu 23.01.2017 o 14:15, Stefan Hajnoczi pisze:
On Fri, Jan 20, 2017 at 10:16:31AM -0800, Junio C Hamano wrote:
My only piece of advice to folks who feel that way is to learn Git
more and get comfortable. You can do neat things like
$ git grep -e pattern rev --
From: "Patrick Steinhardt"
a quick comment on the documentation part ..
The URL matching function computes for two URLs whether they match not.
The match is performed by splitting up the URL into different parts and
then doing an exact comparison with the to-be-matched URL.
The main user of `
y, rather
than the series to avoid spamming.
There are various other low hanging fruit that the eager could look at
which are detailed at the end of the GfW/issues/104 referenced above.
Philip Oakley (4):
git-gui: remove duplicate entries from .gitconfig's gui.recentrepo
gi
eported-by: Alexey Astakhov
Signed-off-by: Philip Oakley
---
lib/choose_repository.tcl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 75d1da8..133ca0a 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repo
setting changed
to a reduced value. Further, when testing the gui's recentrepo
logic it is useful to show these extra, but valid, entries.
Signed-off-by: Philip Oakley
---
lib/choose_repository.tcl | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/choose_repository.
ode to pre-sort and de-duplicate the recentrepo list to
avoid a potential second unset attempt.
Signed-off-by: Philip Oakley
---
lib/choose_repository.tcl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 133ca0
second copy
from the re-read list is performed.
Signed-off-by: Philip Oakley
---
lib/choose_repository.tcl | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index aa87bcc..f39636f 100644
--- a/lib/choose_repository.tcl
From: "Thomas Braun" Friday, January 20, 2017 11:35 PM
Am 20.01.2017 um 23:28 schrieb Philip Oakley:
A recent question on stackoverflow
http://stackoverflow.com/questions/41753252/drop-commits-by-commit-message-in-git-rebase
sought to remove automatically commits that could be ide
A recent question on stackoverflow
http://stackoverflow.com/questions/41753252/drop-commits-by-commit-message-in-git-rebase
sought to remove automatically commits that could be identified by relevant
words in the commit message.
I had thought that the ubiquitous `git filter-branch` should be a
From: "David J. Bakeman"
On 01/14/2017 10:24 PM, Jacob Keller wrote:
On Fri, Jan 13, 2017 at 6:01 PM, David J. Bakeman
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 projec
From: "Junio C Hamano"
v3 1/5] doc: add documentation for OPT_STRING_LIST
Jacob Keller writes:
From: Jacob Keller
Commit c8ba16391655 ("parse-options: add OPT_STRING_LIST helper",
2011-06-09) added the OPT_STRING_LIST as a way to accumulate a repeated
list of strings. However, this was no
From: "Johannes Schindelin"
Hi Philip,
On Mon, 16 Jan 2017, Philip Oakley wrote:
In
https://github.com/git/git/blob/master/git-gui/lib/choose_repository.tcl#L242
the procedure `_unset_recentrepo` is called, however the procedure isn't
declared until line 248. My reading of
I'm looking into a user git-gui problem
(https://github.com/git-for-windows/git/issues/1014) that I'd seen in the
past - I'd started some patches back in Dec 2015
http://public-inbox.org/git/1450310287-4936-1-git-send-email-philipoak...@iee.org/
I'm trying to make sure I have covered the corner c
contrib/gitview has been removed. Remove the reference.
Signed-off-by: Philip Oakley
---
cc: Paul Mackerras
---
Documentation/gitk.txt | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index e382dd9..73c02b9 100644
--- a/Documentation
at default.
Finally document that change.
Signed-off-by: Philip Oakley
---
cc: Shawn O. Pearce
cc: Pat Thoyts
---
Documentation/git-gui.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
index c1a3e8b..5f93f80 100644
---
Match the 'git gui' information regarding the graphical browser
and its upstream location.
Signed-off-by: Philip Oakley
---
cc: Paul Mackerras
---
Documentation/gitk.txt | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitk.txt b/Doc
t; Will merge to 'master'.
Lets remove the reference in the gitk man page, and do some other
fixups while in the area.
Philip Oakley (3):
doc: gitk: remove gitview reference
doc: gitk: add the upstream repo location
doc: git-gui browser does not default to HEAD
Documentation/
From: "Omar Qureshi"
Hi there, I'm not sure this is the best place for this, but, this
seems to be an issue with Git when used through Docker on Windows when
there is a shared volume.
The issue is documented at
https://github.com/bundler/bundler/issues/5322 and I've provided a git
I think thi
From: "Robert Dailey"
On Fri, Jan 6, 2017 at 3:28 PM, Philip Oakley
wrote:
From: "Robert Dailey"
Here's the scenario:
I create a topic branch so one other developer and myself can work on
a feature that takes 2 weeks to complete. During that 2 week period,
change
From: "Robert Dailey"
Here's the scenario:
I create a topic branch so one other developer and myself can work on
a feature that takes 2 weeks to complete. During that 2 week period,
changes are occurring on master that I need in my topic branch. Since
I have a collaborator on the branch, I opt
From: "Jacob Keller"
Sent: Sunday, January 01, 2017 9:24 AM
On Sat, Dec 31, 2016 at 6:32 PM, Junio C Hamano wrote:
Jeff King writes:
On Sat, Dec 31, 2016 at 04:12:40AM +0100, Michael Haggerty wrote:
This is a re-roll of an old patch series. v1 [1] got some feedback,
which I think was all
From: "Michael Haggerty"
This patch series changes a bunch of details about how remote-tracking
references are rendered in the commit list of gitk:
[...]
* Introduce a separate constant to specify the background color used
for the branch name part of remote-tracking references, to allow it
From: "Jacob Keller"
From: Jacob Keller
Commit c8ba16391655 ("parse-options: add OPT_STRING_LIST helper",
2011-06-09) added the OPT_STRING_LIST as a way to accumulate a repeated
list of strings. However, this was not documented in the
api-parse-options documentation. Add documentation now so t
From: "David Aguilar"
On Sat, Dec 10, 2016 at 09:15:34AM +0100, Johannes Sixt wrote:
Am 10.12.2016 um 04:21 schrieb David Aguilar:
> Signed-off-by: David Aguilar
> ---
> This patch builds upon da/mergetool-trust-exit-code
>
> mergetools/tortoisemerge | 2 +-
> 1 file changed, 1 insertion(+),
From: "Klaus Ethgen"
To:
Am Sa den 10. Dez 2016 um 19:18 schrieb Johannes Schindelin:
On Sat, 10 Dec 2016, Klaus Ethgen wrote:
> Am Fr den 9. Dez 2016 um 22:32 schrieb Johannes Sixt:
> > There are too many systems out there that use a backslash in path
> > names. I
> > don't think it is wis
From: "Philip Oakley"
diff --git a/Documentation/gitcore-tutorial.txt
b/Documentation/gitcore-tutorial.txt
index 72ca9c1ef..22309cfb4 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -25,7 +25,7 @@ you want to understand Git's internal
From: "Kristoffer Haugsbakk"
Sent: Friday, December 09, 2016 3:51 PM
What was intended was perhaps "... plumbing does for you" ("you" added),
but
simply omitting the word "for" is more terse and gets the intended point
across
just as well, if not more so.
After some thought, I think the origin
From: "Kristoffer Haugsbakk"
Sent: Friday, December 09, 2016 3:51 PM
By adding the word "just", which might have been accidentally omitted.
Adding the word "just" makes it clear that the point is to *not* do an
octopus merge simply because you *can* do it. In other words, you
should have a rea
From: "Kristoffer Haugsbakk"
Sent: Friday, December 09, 2016 3:51 PM
Instead of using the command 'git clone' as a verb, use "run" as the
verb indicating the action of executing the command 'git clone'.
I would expect 'cloning' as the commonly in use verb here, with the command
then quoted.
From: "Kristoffer Haugsbakk"
Sent: Friday, December 09, 2016 3:51 PM
Add definite and indefinite articles in three places where they were
missing.
- Use "the" in front of a directory name
- Use "the" in front of "style of cooperation"
- Use an indefinite article in front of "CVS background"
Si
From: "Jeff King"
On Sun, Dec 04, 2016 at 11:22:52AM -0000, Philip Oakley wrote:
> Ever since 722ff7f876 (receive-pack: quarantine objects until
> pre-receive accepts, 2016-10-03, v2.11.0), Git has been quarantining
> objects and packs received during an incoming p
From: "Kyle J. McKay"
Sent: Sunday, December 04, 2016 12:24 AM
The recent addition of pre-receive quarantining breaks nested
alternates that are already at the maximum alternates nesting depth.
In the file sha1_file.c in the function link_alt_odb_entries we have
this:
> if (depth > 5) {
>
From: "Brandon Williams"
On 12/01, Ramsay Jones wrote:
On 01/12/16 09:04, Jeff King wrote:
> If a malicious server redirects the initial ref
> advertisement, it may be able to leak sha1s from other,
> unrelated servers that the client has access to. For
> example, imagine that Alice is a git
Be more assertive about the User promise, and Git's defensiveness
of file changes.
Signed-off-by: Philip Oakley
---
Here is a full patch for
https://public-inbox.org/git/7CE3166CFD244DAABF554451E8B0800F@PhilipOakley/
---
Documentation/git-update-index.txt | 22 ++
1
From: "Jeff King"
On Tue, Nov 01, 2016 at 10:28:57AM +, Halde, Faiz wrote:
I frequently use the following command to ignore changes done in a file
git update-index --assume-unchanged somefile
Now when I do a pull from my remote branch and say the file 'somefile'
was changed locally and i
From: "Anders Kaseorg"
On Sun, 30 Oct 2016, Ævar Arnfjörð Bjarmason wrote:
This seems like a reasonable fix for this issue. However as far as I
can tell git-sh-setup was never meant to be used by outside scripts
that didn't ship as part of git itself.
If that's the case any change in the API w
From: "Junio C Hamano"
I hate it when people become overly defensive and start making
excuses when given harmless observations.
Hi Junio,
It can sometimes be difficult for readers to appreciate which way comments
are meant to be interpreted, especially as one cannot usually 'see' the
issu
From: "David Lang"
On Thu, 27 Oct 2016, John Rood wrote:
Thanks, I think changing the default for windows is a good idea.
notepad doesn't work well with unix line endings, wordpad handles the
files much more cleanly.
David Lang
Notepad++ does work well, but isn't a standard part of Win
From: "Johannes Sixt"
One point is that the DCLP idiom must be implemented correctly. There are
solutions, of course, and when the initialization is over, we have a
miniscule overhead at each pthread_mutex_lock call.
I had to look up DCLP ( = Double Checked Locking Patterns), and found a
From: "Junio C Hamano"
Cody Sehl writes:
The first few paragraphs in the git-rebase.txt documentation lay out the
steps git takes during a rebase:
1. everything from `..HEAD` is saved to a temporary area
2. `HEAD` is set to ``
3. the changes held in the temporary area are applied one by one
rt.
All other *.txt ascii art containing three dashes has been checked.
Asciidoctor correctly formats the other art blocks that do contain tabs.
Signed-off-by: Philip Oakley https://git-scm.com/docs/ does not convert this
how-to document to html, rather it links to the Github text pages, which
does
From: "Junio C Hamano"
"Philip Oakley" writes:
It appears that acciidoctor sees the art as being a separated
mono-spaced block, with border/background as locally
appropriate. While the asciidoc looks to simply change to mono-spaced
text.
FWIW, I changed my mind and your
From: "Junio C Hamano"
Philip Oakley writes:
The doc-tool stack does not always respect the 'tab = 8 spaces' rule,
particularly the git-scm doc pages
https://git-scm.com/docs/git-merge-base
and the Git generated html pages.
Sorry, but I do not understand
`git merge-base`
https://public-inbox.org/git/xmqqmvi2sj8f@gitster.mtv.corp.google.com/T/#u
Signed-off-by: Philip Oakley
---
A fixed consistent prefix of tabs is OK, but once that lead is done, stay
with spaces only.
This complements the jc/merge-base-fp-only series.
---
Documentation/git
From: "Junio C Hamano"
"Philip Oakley" writes:
micro-nit: 'first' and 'last' can be tricky to distinguish for lists...
Let's do this then.
Looks good to me. Thanks. -- Philip
-- >8 --
From: Pranit Bauva
Date: Tue, 27 Sep 2016 20:44:09
From: "Pranit Bauva"
Specify even more clearly that --reverse works only with the commits
which are chosen to be shown so as to eliminate the confusion as to
whether the first n or the last n commits with be shown when used
hi Pranit,
micro-nit: 'first' and 'last' can be tricky to distinguish
From:
From: Santiago Torres
Callers of verify-tag may want to cross-check the tagname from refs/tags
with the tagname from the tag object header upon GPG verification. This
is to avoid tag refs that point to an incorrect object.
Add a --format parameter to git verify-tag to print the formatte
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Vegard Nossum"
I use rev^..rev daily, and I'm surely not the only one.
Not everyone knows the 'trick' and may not use it daily.
Consider stating what it is useful for (e.g. "useful t
From: "Vegard Nossum"
I use rev^..rev daily, and I'm surely not the only one.
Not everyone knows the 'trick' and may not use it daily.
Consider stating what it is useful for (e.g. "useful to get the commits and
all commits in the branches that were merged into commit" - paraphrased
from th
Hi Junio,
From: "Junio C Hamano"
"Philip Oakley" writes:
> >"git checkout -b foo" (without -f -m or ) is defined in
> >the manual as being a shortcut for/equivalent to:
> >
> >(1a) "git branch foo"
> >(1b
Ben,
Using a 'bottom / in-line' posting flow is much preferred, which may require
some manual editing[1], hopefully I have it about right...
Philip
--
[1] this is massaged and mangled Outlook Express, sometimes one has to work
with the tools at hand...
From: "Ben Peart"
From: Junio C Hamano
From: "Junio C Hamano"
"Philip Oakley" writes:
Philip probably has a
confused notion that "rev-list A..B C..D" is somehow a union of set
A..B and C..D?
That wasn't the issue. Though it does beg the question that it's the
same as "rev-list D
From: "Junio C Hamano"
"Philip Oakley" writes:
Philip probably has a
confused notion
Hi Junio,
Could you clarify a particular point from here..
The "--no-walk" tells the rev-list machinery "I have only positives;
do not traverse from them AT ALL
From: "Junio C Hamano"
Michael J Gruber writes:
It can be read that
$ git cherry-pick maint next
would pick two single commits, while
$ git cherry-pick maint next ^master
could implicitly be read as
$ git cherry-pick maint next --do-walk ^master
You can read it as "master..next maint"
From: "Junio C Hamano"
"Philip Oakley" writes:
The `git revisions --help` does work ;-)
Not anymore ;-)
I think Ralf Thielow fixed it recently.
hmm, I sort of though it would still work with a valid guide.
I'd only checked with my last GfW version.
--
hey ho
Philip
From: "Paul Williamson"
Hi,
We use git extensively on a number of repos. Recently, we have had a
problem with one of them. This repo has a 'web_dev' branch. For copies of
the repo cloned before a certain (recent but unidentified) time, we could
'git checkout' between master and web_dev and e
From: "Michael J Gruber"
Philip Oakley venit, vidit, dixit 19.09.2016 12:56:
A question came up on the Git user list regarding cherry-pick that got me
reading the manual (again), in this case regarding --no-walk ranges.
Essentially my question is: If --no-walk is given to rev-list
A question came up on the Git user list regarding cherry-pick that got me
reading the manual (again), in this case regarding --no-walk ranges.
Essentially my question is: If --no-walk is given to rev-list (e.g. via
charry-pick), and the user includes a caret prefixed rev, when does that
range def
From: "Philip Oakley"
From: Junio C Hamano
Sent: Saturday, September 17, 2016 5:30 PM
Does it count as simple to use pager's search feature in
"log --raw" output piped to it?
Pardon typos & html; typed on a phone
The `log --raw` looks useful, though I think
From: "Jakub Narębski"
W dniu 17.09.2016 o 20:39, Fredrik Gustafsson pisze:
On Sat, Sep 17, 2016 at 01:47:52PM -0400, Andrew Johnson wrote:
$ git help
$ git --help
$ man git-
I tested all three to confirm they were equivalent.
While I'm not able to answer your question, I can shred a li
old mistakes ;-)
Thanks for the pointer.
On Sep 17, 2016 07:33, "Philip Oakley" wrote:
> Hi,
>
> I'm curating some of my old patch series (i.e. doing some tidying up)
> and
> I'm trying to determine the commits that generated some of my patches so
> t
From: "Fredrik Gustafsson"
On Sat, Sep 17, 2016 at 01:47:52PM -0400, Andrew Johnson wrote:
$ git help
$ git --help
$ man git-
I tested all three to confirm they were equivalent.
It is (IIUC) in a general sort of way "by design", and a little bit of
accident.
While I'm not able to answ
Hi,
I'm curating some of my old patch series (i.e. doing some tidying up) and
I'm trying to determine the commits that generated some of my patches so
that I can see if I still have them after they were rebased (a 'name that
dangling branch' problem).
Is there an easy way of finding the comm
From: "Johannes Schindelin"
Hi Philip,
On Sun, 4 Sep 2016, Philip Oakley wrote:
From: "Johannes Schindelin"
> The point is that fixup! messages are really special, and are always
> intended to be squashed into the referenced commit *before* the latter
> hits
From: "Johannes Schindelin"
Hi Junio & Philip,
On Fri, 2 Sep 2016, Junio C Hamano wrote:
"Philip Oakley" writes:
> As I understand this it's implied by design. The issue is that the
> rebase is looking for that named commit within its current rebase
>
From: "Johannes Schindelin"
Hi,
On Sat, 3 Sep 2016, Jeff King wrote:
On Sat, Sep 03, 2016 at 07:21:18PM -0400, Aaron M Watson wrote:
> Allows stashes to be referenced by index only. Instead of referencing
> "stash@{n}" explicitly, it can simply be referenced as "n".
This says "what" but not
Hi Robert,
From: "Robert Dailey"
On Fri, Sep 2, 2016 at 9:22 PM, Junio C Hamano wrote:
Perhaps a change like this to "rebase -i":
- The search for "original" when handling "pick fixup! original",
when it does not find "original", could turn it into "reword
fixup! original" without chan
From: "Robert Dailey"
Suppose I have a branch with 4 commits, in the following order (as you
might see during interactive rebase):
pick 123 Original Change
pick 789 fixup! Original Change
pick 456 Some Other Thing
pick abc fixup! fixup! Original Change
However, let's say the first commit is al
Hi Junio,
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Junio C Hamano"
"Philip Oakley" writes:
The commit graph. We are looking for F based on knowing J.
. A - B - C - D -- E -- F -- G - H<-first parent, --merges (C,F
From: "Jakub Narębski"
W dniu 29.08.2016 o 15:21, Philip Oakley pisze:
From: "Jakub Narębski"
Sent: Sunday, August 28, 2016 2:01 PM
W dniu 12.08.2016 o 09:07, Philip Oakley pisze:
[...]
+For these commands,
+specifying a single revision, using the notation descri
From: "Jakub Narębski"
Sent: Sunday, August 28, 2016 2:01 PM
W dniu 12.08.2016 o 09:07, Philip Oakley pisze:
[...]
History traversing commands such as `git log` operate on a set
-of commits, not just a single commit. To these commands,
-specifying a single revision with th
From: "Junio C Hamano"
"Philip Oakley" writes:
The commit graph. We are looking for F based on knowing J.
. A - B - C - D -- E -- F -- G - H<-first parent, --merges (C,F,H)
. \ | /\
While trying to answer a Stack Overflow question I thought I could
contribute to, I've found a scenario that I don't understand that may be a
bug.
In http://stackoverflow.com/questions/39144006/identify-merge-into-master
MvG asked how to find the point at which a commit on a feature branch was
From: "Dakota Hawkins"
On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin
wrote:
Hi Dakota,
On Tue, 23 Aug 2016, Dakota Hawkins wrote:
I use GFW almost exclusively, but I pretty much always consult the
upstream documentation anyway (because I find it easier).
Oh... I thought that typin
Sorry if I'm dropping in at the wrong point (this is one I'd bookmarked)..
From: "Duy Nguyen"
Sent: Wednesday, July 20, 2016 3:44 PM
On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin
wrote:
But that strategy *still* ignores the distributed nature of Git. Just
because *you* make that merg
From: "Duy Nguyen"
On Mon, Aug 22, 2016 at 8:06 PM, Johannes Schindelin
wrote:
My point stands. We are way more uninviting to contributors than
necessary. And a huge part of the problem is that we require contributors
to send their patches inlined into whitespace-preserving mails.
We probabl
401 - 500 of 1323 matches
Mail list logo
