Am 8/17/2012 1:35, schrieb Pete Wyckoff:
> +++ b/t/t9815-git-p4-submit-fail.sh
> @@ -0,0 +1,93 @@
> +
> +#!/bin/sh
This initial blank line is an accident, right? ;-)
-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
M
Hello,
we have recently upgraded our Ubuntu server to 12.04, which comes with a newer
version of GIT. However, we have noticed that git archive -remote does not work
anymore by specifying the SHA sum of a commit.
By seaching the mailing list I have found out that this was already discussed
bef
"Philip Oakley" writes:
> From: "Junio C Hamano"
> Sent: Thursday, August 16, 2012 9:23 PM
>> "Philip Oakley" writes:
>>
>>> I wasn't aware of the "abbreviated options" capability. Is meant to
>>> be in the man pages as I couldn't find it, or is it described
>>> differently?
>>
>> $ git help g
Miklos Vajna writes:
> I agree that it's a bit strange, but based on a quick search, it seems
> multiple projects already advertise git pull -r (i.e. not --rebase and
> not a configuration option):
>
> http://lilypond.org/doc/v2.15/Documentation/contributor/pulling-and-rebasing
> http://wiki.docu
On 17/08/12 00:35, Pete Wyckoff wrote:
Send p4d output to a logfile in the $TRASH_DIRECTORY.
Its messages add no value to testing.
I'm not totally sold on this; I still fairly frequently see weird errors
from p4d and these help me work out what's going on. For example, at the
moment if you ru
On 17/08/12 00:35, Pete Wyckoff wrote:
These patches rework how git p4 deals with conflicts that
arise during a "git p4 submit". These may arise due to
changes that happened in p4 since the last "git p4 sync".
Luke: I especially wanted to get this out as you suggested
that you had a different w
On Thu, Aug 16, 2012 at 02:09:33PM -0700, Junio C Hamano
wrote:
> The reason I do not think "pull -r" gives much value to the users to
> trigger "pull --rebase" is because the use of "pull --rebase" is
> very project specific. If you are working on a project that forbids
> merges, you would _alw
Erik Faye-Lund writes:
> On Fri, Jul 27, 2012 at 7:10 PM, Erik Faye-Lund wrote:
>> Since the Windows port of Git expects binary pipes, we need to make
>> sure the helper-end also sets up binary pipes.
>>
>> Side-step CRLF-issue in test to make it pass.
>>
>> Signed-off-by: Erik Faye-Lund
>> ---
Jeff King writes:
> On Fri, Jul 27, 2012 at 09:29:53AM -0400, Jeff King wrote:
>
>> If we put actual files inside "x", which git does track, then they would
>> be part of the stash, and should be properly retained. But they're not:
>>
>> $ rm x && mkdir x && echo foo >x/file
>>
>> Now we have
Junio C Hamano writes:
> Robin Rosenberg writes:
>
>> Just a couple of nitpicks.
>
> Polishing is always good and better late than never, but for a topic
> that has long been graduated to 'master' already, it would be easier
> to review and discuss if it came as a patch form relative to the
> co
Jens Lehmann writes:
> Am 25.07.2012 20:44, schrieb Junio C Hamano:
>> Stefan Zager writes:
>>
>>> Currently, it will only do a checkout if the sha1 registered in the
>>> containing
>>> repository doesn't match the HEAD of the submodule, regardless of whether
>>> the
>>> submodule is dirty.
From: Vitaly _Vi Shukela
Make Ctrl+U for unstaging and Ctrl+J for reverting selection behave
more like Ctrl+T for adding.
They were working only when one area was focused (diff or commit message),
now they should work everywhere.
Signed-off-by: Vitaly _Vi Shukela
---
No reply to previous email
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff King writes:
> On Thu, Aug 16, 2012 at 04:05:22PM -0700, Junio C Hamano wrote:
>
>> Lars Winterfeld writes:
>>
>> >> Hrm, has this ever been resolved?
>> >
>> > Thank you for asking.
>> > My local git version is 1.7.5.4, the server version that I actually
>> > ended up pushing the files to
Hi Junio,
There is one commit on Swedish translation, and it can be added to the
final 1.7.12 release.
The following changes since commit 61b472ed8b090a3e9240590c85041120a54dd268:
git svn: reset invalidates the memoized mergeinfo caches (2012-08-10
19:53:18 +)
are available in the git rep
On Thu, Aug 16, 2012 at 04:05:22PM -0700, Junio C Hamano wrote:
> Lars Winterfeld writes:
>
> >> Hrm, has this ever been resolved?
> >
> > Thank you for asking.
> > My local git version is 1.7.5.4, the server version that I actually
> > ended up pushing the files to was however still some 1.6.x.
Jonathan Nieder writes:
> Ramsay Jones wrote:
>> Junio C Hamano wrote:
>
>>> Observing that all well-written test scripts we have begin with this
>>> boilerplate line:
>>>
>>> test_expect_success setup '
>>>
>>> I wouldn't mind introducing a new helper function test_setup that
>>> behaves lik
This option can be used to prepare the client workspace for
submission, only. It does not invoke the final "p4 submit".
A message describes how to proceed, either submitting the
changes or reverting.
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 7 +++
git-p4.py
A new option, "git p4 submit --dry-run" can be used to verify
what commits and labels would be moved into p4.
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 4
git-p4.py| 43 ++-
t/t9807-git-p4-submit.sh | 41 +
The short form "-v" is common in many git commands as an
alias for "--verbose".
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 2 +-
git-p4.py| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
ind
The user can decide not to continue with a submission,
by not saving the p4 submit template, then answering "no" to
the "Submit anyway?" prompt. In this case, be sure to
return the p4 client to its initial state.
Deleted files were not reverted; fix this and test all cases.
Signed-off-by: Pete W
Put all items in order as they appear, and add comments.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 13c62c6..0e874cb 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1202,6 +12
Test a variety of cases where a patch failed to apply to
p4 and had to be cleaned up.
If the patch failed to apply cleanly, do not try to remove
to-be-added files, as they have not really been added yet.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 2 -
t/t9815-git-p4-submi
When editing the submit template, if no change was made to it,
git p4 offers a prompt "Submit anyway?". Answering "no" cancels
the submit.
Previously, a "no" answer behaves like a "[s]kip" answer to the
failed-patch prompt, in that it proceeded to try to apply the
rest of the commits. Instead, p
When applying a commit to the p4 workspace fails, a prompt
asks what to do next. This belongs up in run() instead
of in applyCommit(), where run() can notice, for instance,
that the prompt is unnecessary because this is the last commit.
Remove the [s]kip option in favor of two new ones: [c]ontinu
Junio C Hamano schrieb:
> Lars Winterfeld writes:
>
>>> Hrm, has this ever been resolved?
>>
>> Thank you for asking.
>> My local git version is 1.7.5.4, the server version that I actually
>> ended up pushing the files to was however still some 1.6.x.
>> So it was a false alarm. Sorry about that.
When a patch failed to apply, these interactive options offered
to:
1) apply the patch anyway, leaving reject (.rej) files around, or,
2) write the patch to a file (patch.txt)
In both cases it suggested to invoke "git p4 submit --continue",
an unimplemented option.
While manually fixing
If a commit fails to apply cleanly to the p4 tree, an interactive
prompt asks what to do next. In all cases (skip, apply, write),
the behavior after the prompt had a few problems.
Change it so that it does not claim erroneously that all commits
were applied. Instead list the set of the patches u
Send p4d output to a logfile in the $TRASH_DIRECTORY.
Its messages add no value to testing.
Signed-off-by: Pete Wyckoff
---
t/lib-git-p4.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index 482eeac..edb4033 100644
--- a/t/lib-git-p4.sh
Signed-off-by: Pete Wyckoff
---
t/lib-git-p4.sh | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index 2d753ab..482eeac 100644
--- a/t/lib-git-p4.sh
+++ b/t/lib-git-p4.sh
@@ -26,9 +26,10 @@ testid=${this_test#t}
git_p4_test_start=9800
These patches rework how git p4 deals with conflicts that
arise during a "git p4 submit". These may arise due to
changes that happened in p4 since the last "git p4 sync".
Luke: I especially wanted to get this out as you suggested
that you had a different way of dealing with skipped commits.
The
Junio C Hamano writes:
> I like the general direction. Perhaps a long distant future
> direction could be to also use the same trick in the ref namespace
> so that we can have 'next' branch itself, and 'next/foo', 'next/bar'
> forks that are based on the 'next' branch at the same time (it
> obvi
Alexey Muranov writes:
> On 20 Jul 2012, at 09:11, Johannes Sixt wrote:
> ...
>> Note the difference between "tracking branch" and "remote tracking
>> branch"! The "remote tracking branches" are the refs in the refs/remotes/
>> hierarchy. The "tracking branches" are your own local branches that y
Dan Johnson writes:
> On Thu, Jul 19, 2012 at 7:55 AM, Jeff King wrote:
> ...
>> So I think it would be a lot more palatable if we kept reflogs on
>> deleted branches. That, in turn, has a few open issues, such as how to
>> manage namespace conflicts (e.g., the fact that a deleted "foo" branch
>
Lars Winterfeld writes:
>> Hrm, has this ever been resolved?
>
> Thank you for asking.
> My local git version is 1.7.5.4, the server version that I actually
> ended up pushing the files to was however still some 1.6.x.
> So it was a false alarm. Sorry about that.
Not really. Pushing or fetching
Inspired by an earlier patch on the list by Tom Xue, but I think
this is done in a much more maintainable way.
It still remains to be seen if this feature makes sense, though.
Signed-off-by: Junio C Hamano
---
date.c | 27 ++-
t/t0006-date.sh | 2 ++
2 files ch
Separate the logic to decide which presentation (e.g. "N months") to
use based on the length of the time from the present and actual
presentation (i.e. "strbuf_addf()"). This is not strictly needed
but will make the next step easier to read.
The format strings lost N_() markings along the way; he
Jundong Xue writes:
> tomxue@ubuntu:~/mycode/life$ git todo
> * d768da9 - (in the future: 3 hours later) Meeting with vendor
> * 5fcd556 - (in the future: 12 days later) Take my personal ho
> * 9dd280b - (in the future: 11 months later)
> * 4680099 - (in the future: 9 months later)
> * 59d5266 -
From: "Junio C Hamano"
Sent: Thursday, August 16, 2012 9:23 PM
"Philip Oakley" writes:
I wasn't aware of the "abbreviated options" capability. Is meant to
be in the man pages as I couldn't find it, or is it described
differently?
$ git help gitcli
is the closest that comes to mind.
If it
Junio C Hamano:
> Jeff King writes:
>
>> On Tue, Jul 03, 2012 at 11:25:16AM +0700, Nguyen Thai Ngoc Duy wrote:
>>
>>> On Tue, Jul 3, 2012 at 10:45 AM, Jeff King wrote:
>>> > On Tue, Jul 03, 2012 at 12:43:42AM +0200, Andreas Schwab wrote:
>>> >
>>> >> Jeff King writes:
>>> >>
>>> >> > It's very
Phil Hord writes:
> So, the next roll will remove the tests for MERGE_RR and will be more
> explicit about the potential for mergetool confusion and/or the fact
> that it is not explicitly tested here.
>
> I'll wait a little longer for any further comments.
Mild ping to a seemingly stalled topic
Carlos MartÃn Nieto writes:
> On Tue, 2012-07-17 at 22:56 -0700, Junio C Hamano wrote:
>> Ping on a seemingly stalled discussion (no need to rush but just
>> checking).
>
> I've implemented the feedback, but been slacking on writing the tests
> which is what's stopped me from re-sending the serie
Jens Lehmann writes:
> Am 09.07.2012 21:38, schrieb Junio C Hamano:
>> Jens Lehmann writes:
>>
>>> Cool, so let's drop this patch and I'll teach "rm" to handle
>>> populated submodules according to what we do for regular files:
>>> Make sure there are no modifications which could get lost (unle
Jeff King writes:
> On Tue, Jul 17, 2012 at 10:10:25PM -0700, Junio C Hamano wrote:
>
>> Ping on a seemingly stalled thread.
>
> Hrm. I could swear that Takeharu sent a follow-up using
> pick_one_utf8_char directly that looked OK, but now I can't seem to find
> it in the list archives. I wonder i
Jeff King writes:
> On Tue, Jul 03, 2012 at 11:25:16AM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> On Tue, Jul 3, 2012 at 10:45 AM, Jeff King wrote:
>> > On Tue, Jul 03, 2012 at 12:43:42AM +0200, Andreas Schwab wrote:
>> >
>> >> Jeff King writes:
>> >>
>> >> > It's very odd for pread to report ENOE
Junio C Hamano writes:
> Johannes Sixt writes:
>
>> Are you sure? This adds '-r', not '--r', i.e., the single-letter option
>> 'r', to the documentation, which is not something we want to hide, usually.
>
> I actually think "--rebase" squatting on short-and-sweet "-r" was an
> accident, and we a
Johannes Sixt writes:
> Are you sure? This adds '-r', not '--r', i.e., the single-letter option
> 'r', to the documentation, which is not something we want to hide, usually.
I actually think "--rebase" squatting on short-and-sweet "-r" was an
accident, and we are saved by not endorsing "pull -r"
Am 16.08.2012 18:22, schrieb Junio C Hamano:
> Miklos Vajna writes:
>
>> ---
>> Documentation/git-pull.txt |1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
>> index defb544..67fa5ee 100644
>> --- a/Documentat
Patrick Sabin writes:
> I read through gitworkflows and want to use the Merge Upwards rule in
> my projects:
>
> "Always commit your fixes to the oldest supported branch that require
> them. Then (periodically) merge the integration branches upwards into
> each other."
>
> This looks great but I
Junio C Hamano writes:
> We would really think hard to avoid breaking when introducing new
> options whose long name could begin with "v" or "q" to avoid
> breaking "-v" and "-q" that are common across commands
[today's lesson for me; do not type while eating]
Sorry.
We would really th
"Philip Oakley" writes:
> I wasn't aware of the "abbreviated options" capability. Is meant to
> be in the man pages as I couldn't find it, or is it described
> differently?
$ git help gitcli
is the closest that comes to mind.
If it is not reachable from "git help git", we may want to sprinkle
Miklos Vajna writes:
> On Thu, Aug 16, 2012 at 09:22:14AM -0700, Junio C Hamano
> wrote:
>> I am not sure if this is worth it, as it comes from a natural
>> "abbreviated options" support, i.e.
>>
>> -r|--r|--re|--reb|--reba|--rebas|--rebase)
>> rebase=true
>
> I sent the patc
From: "Junio C Hamano"
Sent: Thursday, August 16, 2012 5:22 PM
Miklos Vajna writes:
---
Documentation/git-pull.txt |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index defb544..67fa5ee 100644
--- a/Documentatio
I read through gitworkflows and want to use the Merge Upwards rule in my
projects:
"Always commit your fixes to the oldest supported branch that require
them. Then (periodically) merge the integration branches upwards into
each other."
This looks great but I have some trouble in the case if
Hi,
On Thu, Aug 16, 2012 at 09:22:14AM -0700, Junio C Hamano
wrote:
> I am not sure if this is worth it, as it comes from a natural
> "abbreviated options" support, i.e.
>
> -r|--r|--re|--reb|--reba|--rebas|--rebase)
> rebase=true
I sent the patch as a (newcomer) friend tod
From: Jean Tappan
Sent: Thursday, August 16, 2012 12:33 PM
To: 'git@vger.kernel.org'
Subject: Git
I am looking for a tool that will control not only versioning for software, but
also the software's associated user and support manuals. I haven't been able to
find anything that addresses this par
Jeff King writes:
> On Wed, Aug 15, 2012 at 12:22:28PM -0700, Junio C Hamano wrote:
>
>> > The updated rule would be more complex. If a remote nickname is
>> > used, and a refspec given from the command line is without colon, a
>> > new special rule overrides the current behaviour and tries to m
Hi Junio,
On Wed, Aug 15, 2012 at 07:02:31PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > My preference is to remove "static int is_executable()" function
> > from help.c, have an...
> > ... I wouldn't mind seeing the implementation of posix_is_executable()
> > in help.c, which wi
On 08/16/2012 02:00 PM, Thomas Rast wrote:
Michael Haggerty writes:
On 08/16/2012 10:51 AM, Thomas Rast wrote:
I suppose the real problem is that the "true" ordering
is completely obvious as the one ordering that does not require
preprocessing, but ugly to specify in words. Perhaps we can bi
On Thu, 16 Aug 2012 07:11:28 -0600
"J.V." wrote:
> We have a central/shared bare repo setup on a Linux box by our
> scc/build team.
>
> Each developer pulls/pushes to this repo. I have two windows boxes
> where I have cloned the repo. I want to commit and then on my second
> windows box pull
Shawn Pearce writes:
> On Wed, Aug 15, 2012 at 10:42 PM, Junio C Hamano wrote:
> ...
>> An obvious way to record the "delta chain" is to simply keep the
>> name_hash of each object in the pack, which would need 2 bytes per
>> object in the pack, that would bloat pack_idx_entry size from 32
>> by
On Wed, Aug 15, 2012 at 12:22:28PM -0700, Junio C Hamano wrote:
> > The updated rule would be more complex. If a remote nickname is
> > used, and a refspec given from the command line is without colon, a
> > new special rule overrides the current behaviour and tries to match
> > with a configured
Miklos Vajna writes:
> ---
> Documentation/git-pull.txt |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
> index defb544..67fa5ee 100644
> --- a/Documentation/git-pull.txt
> +++ b/Documentation/git-pull.txt
> @@
On Wed, Aug 15, 2012 at 08:59:02AM +0200, Thomas Rast wrote:
> I have never had a need for a fetch that doesn't update the remote
> namespace, nor heard anyone on IRC who has. OTOH, I do have anecdotal
> evidence in support of "the current state is confusing": this thread, or
> the fact that Jan'
Thomas Rast writes:
>> Why not turn the behavior on its head:
>>
>> * Change the default behavior to be something well-defined, easy to
>> document, and convenient for humans, such as "topological order with
>> ties broken by timestamp" or "approximate timestamp order, but
>> respecting dependenc
On Wed, Aug 15, 2012 at 10:42 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> ... But I think its worth giving
>> him a few weeks to finish getting the code ready, vs. rushing
>> something in that someone else thinks might help. We have waited more
>> than 6 years or whatever to improve pac
Luke Diamand writes:
> If I do "git rebase --skip", is there a way to find out the commit SHA
> that was skipped (other than just parsing the output of the command) ?
There currently isn't, and I do not think it is doable in general
when the command ever gives control back to the user to futz wi
We have a central/shared bare repo setup on a Linux box by our scc/build
team.
Each developer pulls/pushes to this repo. I have two windows boxes
where I have cloned the repo. I want to commit and then on my second
windows box pull from my other box and keep those in sync until it is
time t
Michael Haggerty writes:
> On 08/16/2012 10:51 AM, Thomas Rast wrote:
>> I suppose the real problem is that the "true" ordering
>> is completely obvious as the one ordering that does not require
>> preprocessing, but ugly to specify in words. Perhaps we can bikeshed a
>> little? How about
>>
>>
On 08/16/2012 10:51 AM, Thomas Rast wrote:
[...]
is misleading. I suppose the real problem is that the "true" ordering
is completely obvious as the one ordering that does not require
preprocessing, but ugly to specify in words. Perhaps we can bikeshed a
little? How about
By default, commit
Add a documentation of the index file format version 5 to
Documentation/technical.
Helped-by: Michael Haggerty
Helped-by: Junio C Hamano
Helped-by: Thomas Rast
Helped-by: Nguyen Thai Ngoc Duy
Helped-by: Robin Rosenberg
Signed-off-by: Thomas Gummerer
---
Documentation/technical/index-file-fo
Move index version 2 specific functions to their own file,
to prepare for the addition of a new index file format. With
the split into two files we have the non-index specific
functions in read-cache.c and the index-v2 specific functions
in read-cache-v2.c
Helped-by: Nguyen Thai Ngoc Duy
Signed-o
Make the in-memory format aware of the stat_crc used by index-v5.
It is simply ignored by index version prior to v5.
Signed-off-by: Thomas Gummerer
---
cache.h | 1 +
read-cache.c | 25 +
2 files changed, 26 insertions(+)
diff --git a/cache.h b/cache.h
index c77cdb
Make git read the index file version 5 without complaining.
This version of the reader doesn't read neither the cache-tree
nor the resolve undo data, but doesn't choke on an index that
includes such data.
Helped-by: Junio C Hamano
Helped-by: Nguyen Thai Ngoc Duy
Helped-by: Thomas Rast
Signed-o
Make git read the resolve-undo data from the index.
Since the resolve-undo data is joined with the conflicts in
the ondisk format of the index file version 5, conflicts and
resolved data is read at the same time, and the resolve-undo
data is then converted to the in-memory format.
Helped-by: Thom
Write the cache-tree data for the index version 5 file format. The
in-memory cache-tree data is converted to the ondisk format, by adding
it to the directory entries, that were compiled from the cache-entries
in the step before.
Signed-off-by: Thomas Gummerer
---
read-cache-v5.c | 51 +++
Since the cache-tree data is saved as part of the directory data,
we already read it at the beginning of the index. The cache-tree
is only converted from this directory data.
The cache-tree data is arranged in a tree, with the children sorted by
pathlen at each node, while the ondisk format is sor
Write the index version 5 file format to disk. This version doesn't
write the cache-tree data and resolve-undo data to the file.
The main work is done when filtering out the directories from the
current in-memory format, where in the same turn also the conflicts
and the file data is calculated.
H
Make git read the resolve-undo data from the index.
Since the resolve-undo data is joined with the conflicts in
the ondisk format of the index file version 5, conflicts and
resolved data is read at the same time, and the resolve-undo
data is then converted to the in-memory format.
Helped-by: Thom
From: Thomas Rast
Add a performance test for index version [23]/4/5 by using
git update-index --index-version=x, thus testing both the reader
and the writer speed of all index formats.
Signed-off-by: Thomas Rast
Signed-off-by: Thomas Gummerer
---
t/perf/p0002-index.sh | 33 +++
Make update-index always rewrite the index when a index-version
is given, even if the index already has the right version.
This option is used for performance testing the writer and
reader.
Signed-off-by: Thomas Gummerer
---
builtin/update-index.c | 4 +++-
1 file changed, 3 insertions(+), 1 del
Previous rounds of the series are at $gmane/202752 and $gmane/202923
and $gmane/203088.
The modification to t3700 was removed as the smudge marker is replaced
with a CE_SMUDGED flag and therefore the code doesn't interfere with
the test.
Changes since the last round:
[PATCH/RFC v4 01/13] Move i
t2104 currently checks for the exact index version 2 or 3,
depending if there is a skip-worktree flag or not. Other
index versions do not use extended flags and thus cannot
be tested for version changes.
Make this test update the index to version 2 at the beginning
of the test. Testing the skip-wo
Add the possibility of re-reading the index file, if it changed
while reading.
The index file might change during the read, causing outdated
information to be displayed. We check if the index file changed
by using its stat data as heuristic.
Signed-off-by: Thomas Gummerer
---
read-cache.c | 87
---
Documentation/git-pull.txt |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index defb544..67fa5ee 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -101,6 +101,7 @@ include::merge-options
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> We could remove it if you find it confusing.
>>
>> I think the original motivation that line was added was to help
>> people who see "git log" (without any frills) output for the first
>> time not to be alarmed when they see newer things first
Junio C Hamano writes:
> Thomas Rast writes:
>
> > But then the new description is wrong. It claims that children are
> > always before parents, which is not true in the face of clock skew.
>
> Thanks for sanity-check. Here is an updated one.
[...]
> ---topo-order::
> +--date-order::
>
If I do "git rebase --skip", is there a way to find out the commit SHA
that was skipped (other than just parsing the output of the command) ?
I'd like to modify git-p4 so that it can automatically skip past
conflicting changes, but I'd like it to keep a log of which commits
were skipped.
Thanks,
88 matches
Mail list logo
