Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

[Hilco Wijbenga]

On Tue, Jul 31, 2018 at 11:22 PM, Eric Sunshine  wrote:
> On Tue, Jul 31, 2018 at 9:30 PM Hilco Wijbenga  
> wrote:
>> On Tue, Jul 31, 2018 at 12:33 AM, Eric Sunshine  
>> wrote:
>> > This is a re-roll of [1] which fixes sequencer bugs resulting in commit
>> > object corruption when "rebase -i --root" swaps in a new commit as root.
>> > Unfortunately, those bugs made it into v2.18.0 and have already
>> > corrupted at least one repository (a local project of mine). Patches 3/4
>> > and 4/4 are new.
>>
>> Does this also fix losing the initial commit if it is empty?
>>
>> git init ; git commit -m 'Initial commit' --allow-empty ; touch
>> file.txt ; git add file.txt ; git commit -m 'Add file.txt' ; git
>> rebase --root
>>
>> I would expect there to be 2 commits but the first one has
>> disappeared. (This usually happens with "git rebase -i --root" early
>> on in a new project.)
>
> This series should have no impact on that issue; it is fixing root
> commit object corruption, and does not touch or change how the commit
> graph is maintained or how the rebasing machinery itself works (and
> the --allow-empty stuff is part of that machinery).
>
> As Dscho is cc:'d already, perhaps he can chime in as a resident expert.
>
> By the way, what happens if you use --keep-empty while rebasing?

I was not aware of that flag. But, although I was expecting it to, if
I use it with the rebase, I don't see any different behaviour. I can't
really make out what its purpose is from "Keep the commits that do not
change anything from its parents in the result.".

But your suggestion did make me think about what behaviour I would
like to see, exactly. I like that Git removes commits that no longer
serve any purpose (because I've included their changes in earlier
commits). So I would not want to keep commits that become empty during
the rebase. What I would like to see is that commits that _start out_
as empty, are retained. Would such behaviour make sense? Or would that
be considered surprising behaviour?

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

[Hilco Wijbenga]

Hi Eric,

On Tue, Jul 31, 2018 at 12:33 AM, Eric Sunshine  wrote:
> This is a re-roll of [1] which fixes sequencer bugs resulting in commit
> object corruption when "rebase -i --root" swaps in a new commit as root.
> Unfortunately, those bugs made it into v2.18.0 and have already
> corrupted at least one repository (a local project of mine). Patches 3/4
> and 4/4 are new.
>
> v1 fixed these bugs:
>
> * trailing garbage on the commit's "author" header
>
> * extra trailing digit on "author" header's timezone (caused by two
>   separate bugs)
>
> v2 fixes those same bugs, plus:
>
> * eliminates a bogus "@" prepended to the "author" header timestamp
>   which renders the header corrupt
>
> * takes care to validate information coming from
>   "rebase-merge/author-script" before incorporating it into the "author"
>   header since that file may be hand-edited, and bogus hand-edited
>   values could corrupt the commit object.
>

Does this also fix losing the initial commit if it is empty?

Given

git init ; git commit -m 'Initial commit' --allow-empty ; touch
file.txt ; git add file.txt ; git commit -m 'Add file.txt' ; git
rebase --root

I would expect there to be 2 commits but the first one has
disappeared. (This usually happens with "git rebase -i --root" early
on in a new project.)

Cheers,
Hilco

Re: Opinions on changing add/add conflict resolution?

[Hilco Wijbenga]

On Mon, Mar 12, 2018 at 2:35 PM, Jonathan Nieder  wrote:
> Interesting.  I would be tempted to resolve this inconsistency the
> other way: by doing a half-hearted two-way merge (e.g. by picking one
> of the two versions of the colliding file) and marking the path as
> conflicted in the index.  That way it's more similar to edit/edit,
> too.

If work is going to be done in this area, would it be possible to
include making auto-merging (in general) optional? Preferably,
configurable by file (or glob) but I'd already be happy with a global
setting to opt out.

I keep running into bugs caused by Git's automatic merging. (And I
don't see how this could be improved without teaching Git the
specifics of various file types.) It's especially hard when rebasing
large numbers of commits. The bug is introduced early on but I will
not notice anything is wrong until late in the rebase.

(Since I seem to keep asking for things that turn out to already have
been implemented ... if this is already possible please just point me
to the right setting and consider me a happy camper. :-) )

Re: Git should preserve modification times at least on request

[Hilco Wijbenga]

On Mon, Feb 19, 2018 at 3:22 PM, Hilco Wijbenga
<hilco.wijbe...@gmail.com> wrote:
> Aside from exactly which modification times should be used (which I
> would love to have a bit more control over as well), something else
> I'd like to see is that, when switching between branches, files that
> are the same on both branches should not have their modification time
> changed.

As Junio pointed out to me, Git actually already does what I want when
switching branches. To verify, I switched between 5 branches after
setting a specific timestamp on a particular file, and it did not
change throughout the process. Now I'm left wondering when this
changed or whether my memory is faulty. I could have sworn this did
not work previously. :-)

Re: Git should preserve modification times at least on request

[Hilco Wijbenga]

On Mon, Feb 19, 2018 at 2:37 PM, Randall S. Becker
 wrote:
> On February 19, 2018 4:58 PM Johannes wrote:
>> On Mon, 19 Feb 2018, Peter Backes wrote:
>>
>> > please ensure to CC me if you reply as I am not subscribed to the list.
>> >
>> > https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preservi
>> > ng_modification_time_on_files.3F argues that git isn't preserving
>> > modification times because it needs to ensure that build tools work
>> > properly.
>> >
>> > I agree that modification times should not be restored by default,
>> > because of the principle of least astonishment. But should it be
>> > impossible? The principle of least astonishment does not mandate this;
>> > it is not a paternalistic principle.
>> >
>> > Thus, I do not get at all
>> > - why git doesn't *store* modification times, perhaps by default, but
>> > at least on request
>> > - why git doesn't restore modification times *on request*
>> >
>> > It is pretty annoying that git cannot, even if I know what I am doing,
>> > and explicitly want it to, preserve the modification time.
>> >
>> > One use case: I have lots of file lying around in my build directory
>> > and for some of them, the modification time in important information
>> > to me. Those files are not at all used with the build tool. In
>> > contrast to git pull, git pull --rebase needs those to be stashed. But
>> > after the pull and unstash, the mtime is gone. Boo.
>> >
>> > Please provide options to store and restore modification times. It
>> > shouldn't be hard to do, given that other metadata such as the mode is
>> > already stored. It would make live so much easier. And the fact that
>> > this has made into the FAQ clearly suggests that there are many others
>> > who think so.
>>
>> Since you already assessed that it shouldn't be hard to do, you probably
>> want to put your money where your mouth is and come up with a patch, and
>> then offer it up for discussion on this here mailing list.
>
> Putting my large-production-user hat on, there are (at least) three
> conditions that exist in this space:
>
> 1. Build systems - this typically need the file modification time to be set
> to the time at which git touches a file (e.g., checkout). This permits build
> systems to detect that files are modified (even if an older version is
> checked out, make, for example, still needs to see the change to initiate a
> build. My understanding is that current git behaviour is modeled on this use
> case.
>
> 2. Commit linkage - in some environments, files that are checked out are set
> to the timestamp of the commit rather than the original file time or the
> checkout time. This permits a faster production resolution of when changes
> were run through the system as a group. I have implemented this strategy
> (somewhat grudgingly) in a few places. It is a possible desire for some
> users. I particularly dislike this approach because merge/cherry-pick/rebase
> can mess with the preceptive "when" of a change and if you are going to do
> this, make sure that your metadata is suitably managed.
>
> 3. Original file times - as Peter asked, storing the original file time has
> some legacy advantages. This emulates the behaviour of some legacy SCM
> systems and makes people feel better about things. From an audit point of
> view, this has value for systems other than git. In git, you use the
> hash-object to figure out what the file really is, so there is no real audit
> need anymore for timestamps, which can be spoofed at whim anyway. The
> hash-object comment applies to 2 also. Same comment here for dealing with
> non-touching but modifying. For example: what is the timestamp on a
> merge-squash? I would contend that it is the time of the merge-squash, not
> the original time. It could also be an interim term, when a conflict was
> resolved.
>
> Just remember that #2 and #3 break #1, unless you essentially rebuild from
> scratch in every build (ant/maven models). With that said, I seen many repo
> admins who want all of the above, so making them all available would make
> their lives easier.

Aside from exactly which modification times should be used (which I
would love to have a bit more control over as well), something else
I'd like to see is that, when switching between branches, files that
are the same on both branches should not have their modification time
changed.

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

[Hilco Wijbenga]

On Mon, Feb 19, 2018 at 2:36 PM, brian m. carlson
<sand...@crustytoothpaste.net> wrote:
> On Mon, Feb 19, 2018 at 11:35:25AM -0800, Hilco Wijbenga wrote:
>> So a scenario like this:
>>
>> my-branch : X -> A -> B -> C -> D -> E -> F -> G
>> base-branch : X -> Y
>>
>> git rebase --onto base-branch HEAD~7
>> commit A --> conflicts
>> ... lots of work ...
>> commit B --> conflicts
>> ... lots of work ...
>> commit C (Git handles conflicts)
>> commit D (no conflict)
>> commit E --> conflicts
>> ... er, that should have been fixed in commit C
>>
>> How do I keep all the work I did for commits A and B? I get the
>> impression that rerere does not help here because I did not finish the
>> rebase succesfully (and that makes perfect sense, of course). Is there
>> a way at this point in the rebase to "go back" to commit C (so without
>> "git rebase --abort")?
>
> What I do in this case is I unstage all the changes from the index, make
> the change that should have gone into commit C, use git commit --fixup
> (or --squash), and then restage the rest of the changes and continue
> with the rebase.  I can then use git rebase -i --autosquash afterwards
> to insert the commit into the right place.

Yes, that's essentially what I end up doing too. Obviously, in cases
like this, Murphy likes to drop by so commit D will have made changes
to the same files as commit C and you can't cleanly move the fix-up
commit to commit C. :-( I had hoped there might be an easier/cleaner
way to do it.

Is there any way to "interrupt" a rebase?

[Hilco Wijbenga]

Hi all,

When maintaining a long running branch, I regularly rebase onto our
active development branch so that my branch stays up-to-date. What
happens fairly often is that during such a rebase, Git will exit
because of rebase/merge conflicts. Nothing unexpected there, of
course, but as it sometimes turns out, the conflict should have been
fixed in an earlier commit. The only way that I know of to fix this,
is to abort the rebase and start over with "git rebase ...
--interactive" then "edit" every commit and go through them
one-by-one. This is often overkill, though. Is there a better way?
Perhaps I could "rewind" the rebase to an earlier commit and restart
from there?

So a scenario like this:

my-branch : X -> A -> B -> C -> D -> E -> F -> G
base-branch : X -> Y

git rebase --onto base-branch HEAD~7
commit A --> conflicts
... lots of work ...
commit B --> conflicts
... lots of work ...
commit C (Git handles conflicts)
commit D (no conflict)
commit E --> conflicts
... er, that should have been fixed in commit C

How do I keep all the work I did for commits A and B? I get the
impression that rerere does not help here because I did not finish the
rebase succesfully (and that makes perfect sense, of course). Is there
a way at this point in the rebase to "go back" to commit C (so without
"git rebase --abort")?

(Surely, it's not as simple as doing a "git reset --hard
sha-of-commit-C" is it?)

Cheers,
Hilco

Re: Git bisect does not find commit introducing the bug

[Hilco Wijbenga]

On 18 February 2017 at 10:36, Alex Hoffman  wrote:
> You definitely convinced me that git MUST search more than only in the
> paths between good and bad commits, as the good commit G does not have
> to be the first good commit (thank you for that). My problem/confusion
> is that it returns something that does not make sense to me, because
> it does not make sure it returns a transition.

If multiple transitions from GOOD to BAD happen, then I don't see how
binary search is useful/possible. The same is true for a simple list
of numbers, say, 1 5 6 2 3 4. You can't use binary search here because
you can't "throw away" all numbers to the left (or right) of your
pivot. Or am I missing your point?

There are too many unreachable loose objects

[Hilco Wijbenga]

Hi all,

Whenever I run "git push --force(-with-lease)" I get a variation of

Counting objects: 187, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (126/126), done.
Writing objects: 100% (187/187), 21.35 KiB | 0 bytes/s, done.
Total 187 (delta 78), reused 71 (delta 20)
warning: There are too many unreachable loose objects; run 'git prune'
to remove them.
To g...@git.company.com:project.git
 + 51338ea...b0ebe39 my-branch -> my-branch (forced update)

So I'll run "git prune" and, for good measure, "git gc" (which even
includes "git prune"?). The first seems to do nothing, the latter does
its thing.

And then the next time (which could be a few minutes later) I get the
same warning. My branches aren't that big, the largest ever had 40-ish
commits. So abandoning a few dozen commits should not lead to this
warning, I would think.

What am I doing wrong?

Cheers,
Hilco

Re: How to use git show's "%<([,trunc|ltrunc|mtrunc])"?

[Hilco Wijbenga]

On 3 February 2017 at 00:06, Duy Nguyen <pclo...@gmail.com> wrote:
> On Fri, Feb 3, 2017 at 12:51 AM, Hilco Wijbenga
> <hilco.wijbe...@gmail.com> wrote:
>> Hi all,
>>
>> I'm trying to get the committer date printed in a custom fashion.
>> Using "%cI" gets me close:
>>
>> $ git show --format="%cI | %an" master | head -n 1
>> 2017-01-31T17:02:13-08:00 | Hilco Wijbenga
>>
>> I would like to get rid of the "-08:00" bit at the end of the
>> timestamp. According to the "git show" manual I should be able to use
>> "%<([,trunc|ltrunc|mtrunc])" to drop that last part.
>>
>> $ git show --format="%<(19,trunc)cI | %an" master | head -n 1
>
> You're almost there. Just insert another '%' between "trunc)" and "cI".

Thank you so much! This has been bugging me. :-) Rereading "git help
show", I guess it's implied I should do this but it very much wasn't
clear to me (obviously). I guess I'm too used to the "%19.19s" type of
approach. Maybe there should be some examples?

>> How do I get "2017-01-31T17:02:13 | Hilco Wijbenga" to be output?
>
> You'll get an ellipsis at the end though.. (i.e. 02:13... | Hilco)

Indeed, that's not very nice. I suppose I can understand the reason
for it but it mostly defeats the purpose of "trunc", doesn't it?
Luckily, Sylvie's solution does exactly what I want.

Re: How to use git show's "%<([,trunc|ltrunc|mtrunc])"?

[Hilco Wijbenga]

On 2 February 2017 at 20:19, G. Sylvie Davies <syl...@bit-booster.com> wrote:
> On Thu, Feb 2, 2017 at 9:51 AM, Hilco Wijbenga <hilco.wijbe...@gmail.com> 
> wrote:
>> Hi all,
>>
>> I'm trying to get the committer date printed in a custom fashion.
>> Using "%cI" gets me close:
>>
>> $ git show --format="%cI | %an" master | head -n 1
>> 2017-01-31T17:02:13-08:00 | Hilco Wijbenga
>>
>> I would like to get rid of the "-08:00" bit at the end of the
>> timestamp. According to the "git show" manual I should be able to use
>> "%<([,trunc|ltrunc|mtrunc])" to drop that last part.
>>
>> $ git show --format="%<(19,trunc)cI | %an" master | head -n 1
>> cI | Hilco Wijbenga
>>
>> Mmm, it seems to be recognized as a valid "something" but it's not
>> working as I had expected. :-) I tried several other versions of this
>> but no luck. Clearly, I'm misunderstanding the format description. How
>> do I get "2017-01-31T17:02:13 | Hilco Wijbenga" to be output?
>>
>
> Will this work for you?
>
> $ git show -s --pretty='%cd | %an' --date=format:%FT%R:%S
> 2017-02-02T10:01:36 | G. Sylvie Davies

Ah, that does indeed do exactly what I want. Thank you.

> I have no idea how portable this might be.  As "git help log" says:
>
>  --date=format:...  feeds the format ...  to your system
> strftime. Use --date=format:%c to show the date in your system
> locale’s preferred format. See the strftime manual for a complete list
> of format placeholders.

It should be fine for my purposes.

Any idea why "%<(19,trunc)cl" doesn't work? (Your solution solves my
original problem perfectly but I'd like to understand how I'm
misreading the spec.)

How to use git show's "%<([,trunc|ltrunc|mtrunc])"?

[Hilco Wijbenga]

Hi all,

I'm trying to get the committer date printed in a custom fashion.
Using "%cI" gets me close:

$ git show --format="%cI | %an" master | head -n 1
2017-01-31T17:02:13-08:00 | Hilco Wijbenga

I would like to get rid of the "-08:00" bit at the end of the
timestamp. According to the "git show" manual I should be able to use
"%<([,trunc|ltrunc|mtrunc])" to drop that last part.

$ git show --format="%<(19,trunc)cI | %an" master | head -n 1
cI | Hilco Wijbenga

Mmm, it seems to be recognized as a valid "something" but it's not
working as I had expected. :-) I tried several other versions of this
but no luck. Clearly, I'm misunderstanding the format description. How
do I get "2017-01-31T17:02:13 | Hilco Wijbenga" to be output?

Cheers,
Hilco

Re: Force Confirmation for Dropping Changed Lines

[Hilco Wijbenga]

On 25 January 2017 at 18:32, Junio C Hamano  wrote:
> I think you should be able to do something like
>
> $ cat >$HOME/bin/fail-3way <<\EOF
> #!/bin/sh
> git merge-file "$@"
> exit 1
> EOF
> $ chmod +x $HOME/bin/fail-3way
> $ cat >>$HOME/.gitconfig <<\EOF
> [merge "fail"]
> name = always fail 3-way merge
> driver = $HOME/bin/fail-3way %A %O %B
> recursive = text
> EOF
> $ echo pom.xml merge=fail >>.gitattributes
>
> to define a custom merge driver whose name is "fail", that runs the
> fail-3way program, which runs the bog standard 3-way merge we use
> (so that it will do the best-effort textual merge) but always return
> with a non-zero status to signal that the result is conflicting and
> needs manual resolution.

Thank you, that's an improvement. :-) Unfortunately, it still
completes the merge. Is there any way to simply get the
/ markers?

Re: Force Confirmation for Dropping Changed Lines

[Hilco Wijbenga]

On 25 January 2017 at 15:46, Junio C Hamano  wrote:
> Jacob Keller  writes:
>
>>> Mmm, that sounds complex. The "my-code.x" is made up so I could keep
>>> my example as simple as possible. In reality, it's Maven's POM files
>>> (pom.xml).
>>>
>>> So there is no setting for any of this? There is no way to switch off
>>> auto merging for certain files?
>>
>> Not really sure, but a quick google search revealed
>> https://github.com/ralfth/pom-merge-driver
>>
>> Maybe that will help you?
>
> Its readme seems to indicate that it is either solving a different
> problem, or solving the same problem with the opposite goal in mind,
> in that its goal seems to be to forcibly resolve what textually does
> not resolve cleanly by choosing sides with an arbitrary policy, so
> that humans do not have to get involved when they ordinarily would
> have to.
>
> Hilco's goal sounded to me the opposite---to force conflict even
> when the two histories did what textually does resolve cleanly and
> require humans to get involved even when they ordinarily wouldn't
> have to.

Yes, unfortunately, you are correct. This seems to do the exact
opposite of what I want.

Before I start learning about custom merge drivers, is what I want
even possible? If yes, would you happen to know some good examples of
(custom) merge drivers? (Python, Ruby, Java are all okay.)

Re: Force Confirmation for Dropping Changed Lines

[Hilco Wijbenga]

On 25 January 2017 at 14:24, Jacob Keller <jacob.kel...@gmail.com> wrote:
> On Wed, Jan 25, 2017 at 2:16 PM, Hilco Wijbenga
> <hilco.wijbe...@gmail.com> wrote:
>> How can I force Git to not assume my change to the first line is "redundant"?
>>
>
> My guess is that you probably want a custom merge driver for your file
> types. That's where I would look initially.

Mmm, that sounds complex. The "my-code.x" is made up so I could keep
my example as simple as possible. In reality, it's Maven's POM files
(pom.xml).

So there is no setting for any of this? There is no way to switch off
auto merging for certain files?

Force Confirmation for Dropping Changed Lines

[Hilco Wijbenga]

Hi all,

Most of the time, when a later commit changes a line in an identical
fashion during, say, a rebase, you want Git to silently continue by
dropping the duplicate change from the later commit. I have a common
(for me) scenario where I want Git to specifically ask me to resolve
this "conflict" myself instead of simply assuming that the change has
already been applied.

Let's say I have a file my-code.x that starts with a line indicating
its version:

= my-code.x =
VERSION=1.2
line 1
line 2
line 3
=

In my branch my-branch off of master, I make a change:

= my-code.x =
VERSION=1.3
line 1
line 2
line 2a
line 3
=

Now someone else makes a different change on master and pushes it ([1]):

= my-code.x =
VERSION=1.3
line 1
line 2
line 3
line 4
=

When I rebase my-branch onto origin/master, I get no conflicts and
everything seems fine ([2]):

= my-code.x =
VERSION=1.3
line 1
line 2
line 2a
line 3
line 4
=

Except that I should have used VERSION=1.4, not VERSION=1.3 because I
made a change to my-code.x. Obviously, for a single file this is easy
to remember/check but when it's hidden among lots of files and commits
it becomes very hard to find these types of errors.

How can I force Git to not assume my change to the first line is "redundant"?

Cheers,
Hilco

[1] Note that this someone is (correctly) using the same, new version of 1.3.
[2] If my example is actually incorrect, then please just pretend
there are no conflicts.

Re: Git's inconsistent command line options

[Hilco Wijbenga]

On 25 August 2015 at 16:43, Junio C Hamano gits...@pobox.com wrote:
 I do not see a good way to do such a safe transition with command
 words approach, *unless* we are going to introduce new commands,
 i.e. git list-tag, git create-tag, etc.

Perhaps we could introduce a more explicit notion (in .git/config) of
a Git API version (or, perhaps more accurate, a Git CLI API version)?

The default would be 2 (since we're already at Git 2.x). Git commands
could check for this setting and abort/introduce/prevent/change
behaviour/functionality as appropriate. During Git 2.x the API 2 would
be the default but users could explicitly request 3 in preparation of
Git 3.x. (With the knowledge that API 3 would still be [to some extent
at least] in flux.) API 2 could start warning about future changes
where appropriate. With the introduction of Git 3.x, the default would
become API 3 but users could still request API 2. Then for Git 4.x the
default would go to 4, with an option to request 3 but 2 would no
longer be supported (and all code supporting API 2 could be removed).

I think that from a user's point of view this could work quite well.
Obviously, (worst case scenario) Git commands might have to support up
to 3 APIs at the same time (previous [2], current [3], and future [4]
for Git 3.x) so from a code maintenance POV it would certainly
introduce complexity and probably some duplication of code. I'm
hopeful it would be limited to CL argument processing but I suspect
that when Git code calls other Git code (especially in the Bash based
commands) there might be some more complexity there.

Would something like that be feasible?
--
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

Re: [PATCH] init - Honour the global core.filemode setting

[Hilco Wijbenga]

Hi Torsten,

Thank you for taking the time to review my patch.

On 28 September 2014 04:52, Torsten Bögershausen tbo...@web.de wrote:
 On 2014-09-28 02.37, Hilco Wijbenga wrote:
 If ~/.gitconfig contains a core.filemode entry then git init
 should honour that setting.

 Signed-off-by: Hilco Wijbenga hilco.wijbe...@gmail.com
 ---
 This bit me at work where I have to work with Windows. Git on Cygwin
 and the Eclipse Git plugin do not agree on file attributes so I had
 set filemode = false in ~/.gitconfig.
 This feels strange.
 Each and every repo has a core.filemode setting.
 Or should have.

 Did you manage to create a repo without core.filemode in repo/.git/config ?
 And if yes, how?

Perhaps I completely misunderstand the meaning of core.filemode but I
thought it determined whether Git cared about changes in file
properties? So this is client OS related and independent of the repo?

 A few weeks later, I did a git init and, some time later yet, I
 noticed the strange behaviour of Cygwin/Eclipse again.
 I do not fully understand which strange behaviour you experied,
 so I need to guess.

The problem is simply that Eclipse's Git sees changes that Cygwin's
Git does not. It's some sort of unfortunate consequence of trying to
pretend to be Linux on Windows, I guess. The only way to get them to
agree was to set core.filemode to false. Now you might rightly argue
that Eclipse and/or Windows and/or Cygwin should be fixed but that's a
much bigger undertaking than simply setting an existing Git property.
:-)

  This was very
 surprising because things had been working well until then. It took
 quite a bit of research before I realized that git init always sets
 filemode. I think filemode should only be set if not set already
 in the global config (similar to log_all_ref_updates).

 That is part of the whole story:
 In general, git init probes the file system, if the executable bit
 is working as expected.
 So if you  create a Git repository under VFAT, the executable bit is not 
 supported.

 Git will notice that, and set core.filemode = false.

 NTFS is a different story:
 Cygwin has support for the executable bit under NTFS, but Msysit does not.

Agreed. That is what I concluded from the code.

 So if you share a Git repository between Msysgit and cygwin, it may be 
 better
 to set core.filemode to false.

Possibly. I would argue that that is up to the individual developer.

 There is however a problem with your patch, or 2:

 When you set core.filemode = false in your ~/.gitconfig,
 another developer may have core.filemode = true in his config.
 If you manage to share the repo using a network, git will behave different
 for the 2 users.

Isn't that what everything in ~/gitconfig is for? So that I can set
attributes appropriate to my working environment? Besides, that is
already the case if developer A uses a VFAT system and developer B
uses NTFS or JFS or EXTn or ..., right? (As you also indicated above.)

 Solution:
 Set core.filemode for this repo alwways in the repo. (as we do today in 
 git.git)

I suppose you could set it to false, yes. But then it affects
everybody, that seems like going for the lowest common denominator?

 When you run git init with ~/.gitconfig = true, you should
 anyway probe the file system, as it may not support file mode, and 
 core.filemode may be false.


 So the solution that I can see is:
 (Some pseudo-code:)

 if (git config (global config ) == false) ||
(git config (~/.config ) == false) then
   git_config_set(core.filemode, false);
 else
   probe the file system and set core.filemode as we do today
 fi

Yeah, I actually considered that (well, something less complete,
actually :-) ) but decided to go for the simpler approach that I
showed. My assumption is that the developer working with the repo
knows what he is doing. It seems wrong for Git to override that
decision. Then again, I don't really see any advantage in setting
core.filemode to true when working with, say, a VFAT filesystem, so
ignoring it in that case might be okay. Would such a setup do active
damage, though?

 The usual caveat applies: this is my first patch. Having said that,
 please feel free to be pedantic and strict. It's a small patch so I
 would imagine that fixing any problems should not take long (assuming
 it is acceptable at all, of course). I'd like to know I did it right.
 :-)

 AFAICT, all tests passed. Should a separate test be added for this change?
 I think yes.

Okay, I'll have to figure out how to do that.

 Under which system did you test ?

 Windows?
 CYWGIN ?
 MingWW/Msysgit ?
 Linux ?

Only Linux. I don't really run Windows at home.

 - /* Check filemode trustability */
 - filemode = TEST_FILEMODE;
 - if (TEST_FILEMODE  !lstat(path, st1)) {
 - struct stat st2;
 - filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) 
 - !lstat(path, st2) 
 - st1.st_mode != st2.st_mode);
 + /* Do not override the global filemode setting. */
 + if (trust_executable_bit == -1) {
 + /* Check filemode

[PATCH] init - Honour the global core.filemode setting

[Hilco Wijbenga]

If ~/.gitconfig contains a core.filemode entry then git init
should honour that setting.

Signed-off-by: Hilco Wijbenga hilco.wijbe...@gmail.com
---
This bit me at work where I have to work with Windows. Git on Cygwin
and the Eclipse Git plugin do not agree on file attributes so I had
set filemode = false in ~/.gitconfig.

A few weeks later, I did a git init and, some time later yet, I
noticed the strange behaviour of Cygwin/Eclipse again. This was very
surprising because things had been working well until then. It took
quite a bit of research before I realized that git init always sets
filemode. I think filemode should only be set if not set already
in the global config (similar to log_all_ref_updates).

The usual caveat applies: this is my first patch. Having said that,
please feel free to be pedantic and strict. It's a small patch so I
would imagine that fixing any problems should not take long (assuming
it is acceptable at all, of course). I'd like to know I did it right.
:-)

AFAICT, all tests passed. Should a separate test be added for this change?

(I used git format-patch and git imap-send to send this patch to
the ML but looking below I still do not see tabs? In fact, I do not
see any indentation.)
 builtin/init-db.c | 19 +++
 environment.c |  2 +-
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/builtin/init-db.c b/builtin/init-db.c
index 56f85e2..19cdc58 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -248,15 +248,18 @@ static int create_default_files(const char *template_path)
  path[len] = 0;
  strcpy(path + len, config);

- /* Check filemode trustability */
- filemode = TEST_FILEMODE;
- if (TEST_FILEMODE  !lstat(path, st1)) {
- struct stat st2;
- filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) 
- !lstat(path, st2) 
- st1.st_mode != st2.st_mode);
+ /* Do not override the global filemode setting. */
+ if (trust_executable_bit == -1) {
+ /* Check filemode trustability */
+ filemode = TEST_FILEMODE;
+ if (TEST_FILEMODE  !lstat(path, st1)) {
+ struct stat st2;
+ filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) 
+ !lstat(path, st2) 
+ st1.st_mode != st2.st_mode);
+ }
+ git_config_set(core.filemode, filemode ? true : false);
  }
- git_config_set(core.filemode, filemode ? true : false);

  if (is_bare_repository())
  git_config_set(core.bare, true);
diff --git a/environment.c b/environment.c
index 565f652..875a498 100644
--- a/environment.c
+++ b/environment.c
@@ -12,7 +12,7 @@
 #include fmt-merge-msg.h
 #include commit.h

-int trust_executable_bit = 1;
+int trust_executable_bit = -1;
 int trust_ctime = 1;
 int check_stat = 1;
 int has_symlinks = 1;
-- 
2.1.1.dirty
--
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

Re: [PATCH v2 try2 00/14] Officially start moving to the term 'staging area'

[Hilco Wijbenga]

On 25 April 2014 11:12, Felipe Contreras felipe.contre...@gmail.com wrote:
 It has been discussed many times in the past that 'index' is not an
 appropriate description for what the high-level user does with it, and
 it has been agreed that 'staging area' is the best term.

 The term 'staging area' is more intuitive for newcomers which are more
 familiar with English than with Git, and it seems to be a
 straightforward mental notion for people with different mother tongues.

 In fact it is so intuitive that it's used already in a lot online
 documentation, and the people that do teach Git professionally use this
 term, because it's easier for many kinds of audiences to grasp.

While the implementation looks okay to me, I will not pretend to be a
good judge of that so I will leave that to others. But I definitely
welcome the API change this produces.
--
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

Re: [Proposal] Clonable scripts

[Hilco Wijbenga]

On 9 September 2013 13:48, Niels Basjes ni...@basjes.nl wrote:
 If those scripts were how ever written in a language that is build
 into the git program and the script are run in such a way that they
 can only interact with the files in the local git (and _nothing_
 outside of that) this would be solved.

That sounds interesting.

 Also have a builtin scripting language also means that this would run
 on all operating systems (yes, even Windows).

This would be *very* helpful. It's a total pain trying to get hooks
working across different OSes.

 So I propose the following new feature:

 1) A scripting language is put inside git. Perhaps a version of python
 or ruby or go or ... (no need for a 'new' language)

That sounds nice but ...

 2) If a project contains a folder called .githooks in the root of the
 code base then the rules/scripts that are present there are executed
 ONLY on the system doing the actual commit. These scripts are run in
 such a limited way that they can only read the files in the
 repository, they cannot do any networking/write to disk/etc and they
 can only do a limited set op actions against the current operation at
 hand (i.e. do checks, parse messages, etc).

... how would you prevent Ruby/Python/Go/$GeneralProgLang from
executing arbitrary code?

 Like I said, this is just a proposal and I would like to know what you
 guys think.

I love the idea but I'm not sure how feasible it is. I think you would
be forced to copy an existing language and somehow make it secure
(seems like a maintenance nightmare) or to create your own language
(potentially a lot of work). But perhaps something more declarative
might be usable?
--
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

Re: Officially start moving to the term 'staging area'

[Hilco Wijbenga]

On 6 September 2013 08:45, Ping Yin pkufra...@gmail.com wrote:
 On Wed, Sep 4, 2013 at 2:08 PM, William Swanson swanson...@gmail.com wrote:
 On Thu, Aug 29, 2013 at 11:01 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 It has been discussed many times in the past that 'index' is not an
 appropriate description for what the high-level user does with it, and
 it has been agreed that 'staging area' is the best term.

 I realize Git is not a democracy, but if the vote of a humble user
 counts for anything, I agree that index is a terrible name.

 +1 for staging area

As yet another just a user, I'd like to add my enthusiastic support
for to stage and staging area.

I'm guessing that a lot of Git devs/long time users are simply so used
to its interface that they may not see its sharp corners any more. :-)
That's quite natural and bound to happen to anyone who works with a
particular tool for a long time. Still, (e.g.) git add -A removing
files (as useful as that is) is just weird. And, in general, the user
should not need to know how Git is implemented.

 I was very excited when Felipe first started this thread, since I
 thought Git might finally fix one of it's biggest long-standing
 usability problems.

 the same feeling.

Ditto. :-)
--
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

Flatten history

[Hilco Wijbenga]

Hi all,

I have a (public) feature branch that has been kept up-to-date with
master by regularly merging master back into it. I would now like to
get all the changes from feature but not any of the commits.
Basically, I want to replay all of feature's commits without creating
those commits.

I thought something like

git cherry-pick -n abcd^..feature

should do the trick (while on master, where abcd is the SHA-1 of the
commit where feature was created) but I get conflicts.

First, why the conflicts? I have done all the merges so cherry-pick
should simply be able to replay them? Second, what is the correct way
of doing this?

Cheers,
Hilco

P.S. The most annoying thing is that I've done this exact thing before
but I can't find what command I used. :-)
--
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

Re: Flatten history

[Hilco Wijbenga]

On 29 July 2013 20:50, Felipe Contreras felipe.contre...@gmail.com wrote:
 On Mon, Jul 29, 2013 at 8:42 PM, Hilco Wijbenga
 hilco.wijbe...@gmail.com wrote:
 Hi all,

 I have a (public) feature branch that has been kept up-to-date with
 master by regularly merging master back into it. I would now like to
 get all the changes from feature but not any of the commits.
 Basically, I want to replay all of feature's commits without creating
 those commits.

 I thought something like

 git cherry-pick -n abcd^..feature

 should do the trick (while on master, where abcd is the SHA-1 of the
 commit where feature was created) but I get conflicts.

 First, why the conflicts? I have done all the merges so cherry-pick
 should simply be able to replay them? Second, what is the correct way
 of doing this?

 Perhaps

 % git cherry-pick -n --no-merges --right-only --topo-order
 --cherry-pick abcd^..feature

Thank you for the suggestion but this still gives me conflicts.
--
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

Re: Flatten history

[Hilco Wijbenga]

On 29 July 2013 20:59, Bryan Turner btur...@atlassian.com wrote:
 On 30 July 2013 13:50, Felipe Contreras felipe.contre...@gmail.com wrote:
 On Mon, Jul 29, 2013 at 8:42 PM, Hilco Wijbenga
 hilco.wijbe...@gmail.com wrote:
 Hi all,

 I have a (public) feature branch that has been kept up-to-date with
 master by regularly merging master back into it. I would now like to
 get all the changes from feature but not any of the commits.
 Basically, I want to replay all of feature's commits without creating
 those commits.

 I thought something like

 git cherry-pick -n abcd^..feature

 should do the trick (while on master, where abcd is the SHA-1 of the
 commit where feature was created) but I get conflicts.

 First, why the conflicts? I have done all the merges so cherry-pick
 should simply be able to replay them? Second, what is the correct way
 of doing this?

 Perhaps

 % git cherry-pick -n --no-merges --right-only --topo-order
 --cherry-pick abcd^..feature

 --
 Felipe Contreras

 Wouldn't git merge --squash do what you're looking for? It seems like
 the only way to not get conflicts trying to cherry pick is if you
 never had any conflicts while you were merging master into your
 feature branch. Evil merges, where you actually have to change code,
 even if it's just to resolve conflicts, don't tend to replay
 correctly.

 It seems like this should do it:
 % git checkout master
 Switched to branch 'master'
 % git merge --squash feature
 Squash commit -- not updating HEAD
 Automatic merge went well; stopped before committing as requested
 % git commit

 git merge --squash will just apply the changes without creating a
 commit. You can then make any final changes you want to and write your
 commit message for the feature.

Ah, yes git merge --squash feature seems to do exactly what I was
looking for. Funny, I thought I did something with rev-list last time
but this --squash is much simpler. :-) Thank you!
--
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

Re: [Request] Git reset should be able to ignore file permissions

[Hilco Wijbenga]

On 19 June 2013 01:00, Alexander Nestorov alexander...@gmail.com wrote:
 Ok, this is how it looks. If everything is ok, I'm sending it to the ML

 From 262bdfb5cc84fec7c9b74dc92bb604f9d168ef9a Mon Sep 17 00:00:00 2001
 From: Alexander Nestorov alexander...@gmail.com
 Date: Wed, 19 Jun 2013 09:55:42 +0200
 Subject: [PATCH] Add example for reseting based on content changes instead of
  stat changes

 ---
  Documentation/git-reset.txt | 12 
  1 file changed, 12 insertions(+)

 diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
 index a404b47..da639e9 100644
 --- a/Documentation/git-reset.txt
 +++ b/Documentation/git-reset.txt
 @@ -289,6 +289,18 @@ $ git reset --keep start3
  3 But you can use reset --keep to remove the unwanted commit after
  you switched to branch2.

 +Reset only files who's content changed (instead of stat information)::

You should use whose here instead of who's.

 ++
 +
 +$ git update-index --refresh   1
 +$ git reset --hard 2
 +
 ++
 +1 Make Git realize which files actually changed instead of
 +checking out all files whether their content changed or only
 +their mtime changed.
 +2 Now git reset --hard will checkout only the files that
 +actually changed.

  DISCUSSION
  --
 --
 1.8.1.msysgit.1
 --
 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
--
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

Re: New feature discussion: git rebase --status

[Hilco Wijbenga]

On 11 June 2013 06:19, Matthieu Moy matthieu@grenoble-inp.fr wrote:
 John Keeping j...@keeping.me.uk writes:

 The one piece of information that I often want is the SHA1 of the commit
 that is currently being applied.  Currently I have to look through my
 scrollback for the stopping message or poke around in .git/.

 Having that in the output of git status would be really nice,

 ... and should be rather easy as it is the content of
 .git/rebase-merge/stopped-sha

 Perhaps git status could say stg like (applying 1d3fb08, 2/5)

 output format you've posted is a big improvement over what we have at
 the moment for this case.

 My idea when I wrote the item on the wiki was to keep the a very short
 summary in git status, and to put all the information one could whish
 in a separate command. I'd describe it as a complement more than an
 improvement ;-).

Having git status display (even more) context sensitive
information during git rebase or git merge would be very welcome.
Please, if at all possible, don't make that a separate command.
--
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

Re: git send-email should not allow 'y' for in-reply-to

[Hilco Wijbenga]

On 11 January 2013 08:47, Jeff King p...@peff.net wrote:
 On Fri, Jan 11, 2013 at 09:39:06AM -0700, Eric Blake wrote:

  Please don't answer y when git send email shows the following prompt:
 
  Message-ID to be used as In-Reply-To for the first email?
 
  you should respond with a message ID there. Unfortunately we have a
  growing thread that contains submissions with this mistake.

snip/

   People answer 'y' to Who should the emails appear to be from?  and
   'n' to Message-ID to be used as In-Reply-To for the first email?
   for some unknown reason.  While it is possible that your local
   username really is y and you are sending the mail to your local
   colleagues, it is possible, and some might even say it is likely,
   that it is a user error.

I have never used Git's email support so this doesn't affect me one
way or another but it seems that checking the results is fixing the
symptoms, not the problem? I apologize if this was already discussed
but I couldn't find such a discussion.

I was wondering if it might be a better idea to change the wording of
the questions if they have proven so confusing? The first time (just
now) that I read Message-ID to be used as In-Reply-To for the first
email?, it clearly seemed like a yes/no question to me. :-)

How about What Message-ID to use as In-Reply-To for the first email?
or Provide the Message-ID to use as In-Reply-To for the first
email:. I'm a little surprised that Who should the emails appear to
be from? would be interpreted as a yes/no question but we could
rephrase that similarly as Provide the name of the email sender: (I
don't really like this particular version but you get the idea).
--
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

Re: /* in .gitignore

[Hilco Wijbenga]

On 25 September 2012 16:13, Junio C Hamano gits...@pobox.com wrote:
 Hilco Wijbenga hilco.wijbe...@gmail.com writes:

 Naturally, this behaviour makes perfect sense: /* means everything.
 Still, I was wondering whether it might be a good idea to make an
 exception for '.gitignore' itself? Then if somebody *really* wanted to
 ignore '.gitignore' they could add /.gitignore to '.gitignore'?

 If somebody is sick enough to ignore everything, he can add /*
 to the .gitignore file and in order to make sure he knows what he is
 doing and he is doing what he thinks is doing, he would check with
 git diff --stat HEAD etc. before committing, and double check with
 git show --stat etc. after committing.

Ignoring everything is not quite so sick. :-) My use case is
Eclipse's .metadata directory. This directory is *huge* but only
.metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs is
really of interest (and not even all of those files). The subset of
*.prefs that we are interested in will allow us to share Eclipse
configuration settings (things like formatting settings and which
warnings we care about). So I have several '.gitignore' files with
/* + !/some-dir/. [To make things even more interesting, the
.settings directory should be ignored in all other places (so it's
in our top level '.gitignore').]

I would be very happy to find out better ways to handle this
particular scenario. I had quite a struggle getting it to work.

 .gitignore (or .gitattributes for that matter) shouldn't be any
 different from your ordinary tracked contents.  If you have *.o in
 the ignored pattern list, you would need an extra care to defeat the
 pattern to add vendor-supplied binary-only object file with add -f
 and live with the fact that a new vendor-supplied binary-only object
 file not appearing on untracked list.  It is exactly the same deal.

I do not entirely agree. I think '.gitignore' *is* different. This
file is special and affects Git's behaviour. And it does so *before*
it has been committed. Or even added. The fact that '.gitignore'
itself is not listed in the output of, e.g., git status is easy to
miss.

I have not really used '.gitattributes' but I assume the same applies.

 Having said that, I guess you could add !.git* to your
 $GIT_DIR/info/exclude and see if it gives an improved user
 experience.

Mmm, that does not seem to help. I did

git init  touch file.txt  echo '/*'.gitignore  echo
'!.gitignore' .git/info/exclude  git status

it lists nothing (Git 1.7.12). I had expected to see '.gitignore'. Did
I misunderstand you?

Even so, this would only improve *my* user experience, wouldn't it?
This would not get pushed to the central repository so it would not
help anyone else.
--
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

Re: a small git proposal

[Hilco Wijbenga]

On 23 August 2012 08:10, Catalin Pol catalin@gmail.com wrote:
 Hi everyone,

 This is my first email to this mailing list, so this may be somehow
 too straight forward... the idea is that I was thinking to develop a
 new feature in Git (although I'm kind of new to git myself).
 I wrote a small description of what I intend to do and I figured I
 could use some pointers (how I can improve it, any possible usage
 scenarios you can think for it and so on). Details are available at
 the gist link below or as attachment to this email (I zipped the text
 file since it was more it is larger than 10k and I didn't want it to
 get rejected by the email server... although it still might)

 gist link:https://gist.github.com/3437530

 I made the gist public, so feel free to edit it directly... or, if you
 prefer, just email me with any comments. I'm opened to any suggestion,
 so feel free to send me any kind of comment (maybe I'm trying to
 implement something that is already in git for example, and since I'm
 a bit of a newbie in the git world, I didn't notice any way to obtain
 my desired workflow).

 Thanks in advance for any feedback,

Have you looked at git notes?
--
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

Re: Your branch and 'origin/master' have diverged

[Hilco Wijbenga]

On 14 August 2012 01:27, Thomas Rast tr...@student.ethz.ch wrote:
 Hilco Wijbenga hilco.wijbe...@gmail.com writes:

 # On branch master
 # Your branch and 'origin/master' have diverged,
 # and have 250 and 19 different commit(s) each, respectively.
 #
 nothing to commit (working directory clean)

 He asked me what to do and I told him to do what has always worked for
 me in the past when something like this happened: gitk, reset master
 branch to here (to a commit before the divergence and using --hard),
 git pull origin master. Problem solved.

 There are several layers of pitfalls and misunderstandings here.

 * Is your work origin/master..master (that is, anything in master but
   not origin/master) really so worthless as to make scrap it all! the
   normal course of resolution?

Of course, it's master. Nobody should be working on master directly.

   Or perhaps the real reason for the divergence is that upstream rewrote
   its master (k!), in which case you should get them acquainted with
   the clue bat... and probably rebase instead of merge.

Upstream is fine. Nobody else is having any problems.

 * pull = fetch + merge!  Repeat this a few times until it sinks in.
   Then print it on A0 and stick it up in your office or something.

Yes, I know.

   For your case this means that the pull command is roughly equivalent
   to

 git fetch origin master
 git merge FETCH_HEAD

   The two-arg form of fetch does *not* update origin/master.  Assuming
   you got the reset right, the merge will fast-forward to whatever
   origin's master points to -- but origin/master is still the old state!

Ah, now we're getting to something I did *not* know. :-) So FETCH_HEAD
!= origin/master? I tried to find out more information about
FETCH_HEAD but there doesn't seem to be much. I have seen FETCH_HEAD
show up in the terminal but always just ignored it as a Git
implementation detail. When/how does origin/master get set then? I
always assumed that was part of git fetch and then git merge would
actually move master to origin/master.

 * Resetting to something that you think will fast-forward, only to then
   fast-forward it to the newest state, is silly.  You can just reset to
   the newest state instead.

:-) Well, yeah, now that you point it out... :-)

Still, just resetting ignores all the problems that led to the current
situation. Normally, when I reset and then FF I can be sure (if it
works) that things were not completely screwed up. At least, that has
always been my theory.

 Taking all of this together, I think you should stop using two-arg
 pull[*] or fetch, and replace your error-prone recipe with simply

   git fetch
   git reset --hard origin/master

 Assuming, as before, that your local work is worthless.  Is it?
 Otherwise it would be better to run something like

   git fetch
   git rebase origin/master


 [*] it's ok if you use it with an URL instead of a remote nickname

Why would that be okay? What is the difference? Isn't the nickname
just an alias for a URL?
--
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

Re: Your branch and 'origin/master' have diverged

[Hilco Wijbenga]

On 14 August 2012 09:02, PJ Weisberg p...@irregularexpressions.net wrote:
 On Mon, Aug 13, 2012 at 12:58 PM, Hilco Wijbenga
 hilco.wijbe...@gmail.com wrote:
 Hi all,

 A colleague of mine (after a relatively long absence) noticed the
 following when running git status:

 # On branch master
 # Your branch and 'origin/master' have diverged,
 # and have 250 and 19 different commit(s) each, respectively.
 #
 nothing to commit (working directory clean)

 He asked me what to do and I told him to do what has always worked for
 me in the past when something like this happened: gitk, reset master
 branch to here (to a commit before the divergence and using --hard),
 git pull origin master. Problem solved.

 Well, not this one. This one is persistent. :-) I am at a loss what to
 do. master and origin/master do *not* point at the same commit.
 Even after the git reset --hard ... and git pull. Running my
 silver bullet solution gets us in the same situation every time.

 I assume that the commit you reset to wasn't actually before the
 divergence, then.

It was according to gitk.

 It sounds like what you're trying to do is just
 long-hand for 'git reset --hard origin/master'.  As mentioned before,
 that *does* assume that you want to throw out everything you've
 committed locally.  If that's *not* the case, try 'git rebase
 origin/master' or 'git pull --rebase'.  And then go slap the person
 who rewrote the history of origin/master.

I'm not convinced anything is wrong with origin/master. This
particular colleague is the only one with a problem. And not for the
first time. :-)
--
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

Re: Your branch and 'origin/master' have diverged

[Hilco Wijbenga]

On 14 August 2012 10:19, Junio C Hamano gits...@pobox.com wrote:
 Hilco Wijbenga hilco.wijbe...@gmail.com writes:

 On 14 August 2012 01:27, Thomas Rast tr...@student.ethz.ch wrote:
 Hilco Wijbenga hilco.wijbe...@gmail.com writes:

 # On branch master
 # Your branch and 'origin/master' have diverged,
 # and have 250 and 19 different commit(s) each, respectively.
 #
 nothing to commit (working directory clean)

 He asked me what to do and I told him to do what has always worked for
 me in the past when something like this happened: gitk, reset master
 branch to here (to a commit before the divergence and using --hard),
 git pull origin master. Problem solved.

 There are several layers of pitfalls and misunderstandings here.

 * Is your work origin/master..master (that is, anything in master but
   not origin/master) really so worthless as to make scrap it all! the
   normal course of resolution?

 Of course, it's master. Nobody should be working on master directly.

 What a strange thing to say.  When will 'master' ever be updated
 then and how?

Well, yes, just before pushing, you'd work on master for a few
seconds. That doesn't really count. :-)

 If you mean 'master' as the integration branch for everybody to meet
 and make progress, it would be more common for everybody to be
 working on his own topic branch until perfection of the topic,
 concluded by merging the completed topic to master and pushing the
 master out to update it, no?

That's what I should have said. I assumed way too much context. I
don't think all neurons are firing yet. :-(

 * pull = fetch + merge!  Repeat this a few times until it sinks in.
   Then print it on A0 and stick it up in your office or something.

 Yes, I know.

   For your case this means that the pull command is roughly equivalent
   to

 git fetch origin master
 git merge FETCH_HEAD

   The two-arg form of fetch does *not* update origin/master.  Assuming
   you got the reset right, the merge will fast-forward to whatever
   origin's master points to -- but origin/master is still the old state!

 Ah, now we're getting to something I did *not* know. :-) So FETCH_HEAD
 != origin/master?

  I tried to find out more information about
 FETCH_HEAD but there doesn't seem to be much. I have seen FETCH_HEAD
 show up in the terminal but always just ignored it as a Git
 implementation detail. When/how does origin/master get set then? I
 always assumed that was part of git fetch and then git merge would
 actually move master to origin/master.

 It could be git fetch --help is failing for you, but I am
 reasonably sure most if not all of the above are answered there;
 another thing something you may not have known :-).

I was actually looking at git help merge since git help fetch
would be a far too logical place for FETCH_HEAD information. ;-) As I
said, not all neurons seem to be firing yet.

Apparently, my understanding is mostly correct, though. FETCH_HEAD is
indeed origin/master (I mean the SHA1 in master's HEAD on origin) and
the git merge part of git pull eventually sets my origin/master.

 Taking all of this together, I think you should stop using two-arg
 pull[*] or fetch, and replace your error-prone recipe with simply

   git fetch
   git reset --hard origin/master

 Assuming, as before, that your local work is worthless.  Is it?
 Otherwise it would be better to run something like

   git fetch
   git rebase origin/master

 Yeah, the latter makes sense, and I think it is a safer superset of
 the former.  If there is nothing of value on 'master', the rebase
 might stop and give control back to the user, but the user can tell
 it to skip the cruft that came from the old 'master'.

 [*] it's ok if you use it with an URL instead of a remote nickname

 Why would that be okay? What is the difference? Isn't the nickname
 just an alias for a URL?

 As long as you tell what refspecs to use on the command line, the
 remote nickname behaves as just an alias for a URL, so yes,
 because Thomas is discussing two-arg pull or fetch, one arg being
 either nickname or URL and the other is an explicit refspec on the
 command line, it would be okay because there is no difference in
 that case.

I suppose I'm not entirely clear on how this two step process is
safer. Doing git fetch would seem to be harmless, right? So the
problem is with git merge but master should always be behind
origin/master so that git merge should just FF to origin/master
which *should* be completely safe. Does that make sense? Especially
given our use of master as an integration branch?

[Given the trouble I have with getting people to use Git properly, I
prefer things as simple as possible. :-) ]
--
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

Re: Your branch and 'origin/master' have diverged

[Hilco Wijbenga]

On 14 August 2012 13:12, Thomas Rast tr...@student.ethz.ch wrote:
 Hilco Wijbenga hilco.wijbe...@gmail.com writes:

 On 14 August 2012 10:19, Junio C Hamano gits...@pobox.com wrote:
 Hilco Wijbenga hilco.wijbe...@gmail.com writes:

 On 14 August 2012 01:27, Thomas Rast tr...@student.ethz.ch wrote:
 [git pull with two args] it's ok if you use it with an URL instead
 of a remote nickname

 Why would that be okay? What is the difference? Isn't the nickname
 just an alias for a URL?

 As long as you tell what refspecs to use on the command line, the
 remote nickname behaves as just an alias for a URL, so yes,
 because Thomas is discussing two-arg pull or fetch, one arg being
 either nickname or URL and the other is an explicit refspec on the
 command line, it would be okay because there is no difference in
 that case.

 I suppose I'm not entirely clear on how this two step process is
 safer. Doing git fetch would seem to be harmless, right? So the
 problem is with git merge but master should always be behind
 origin/master so that git merge should just FF to origin/master
 which *should* be completely safe. Does that make sense? Especially
 given our use of master as an integration branch?

 [Given the trouble I have with getting people to use Git properly, I
 prefer things as simple as possible. :-) ]

 I meant something else than Junio hinted at.  Saying

   git fetch origin master
   # or by extension
   git pull origin master

 does not update the origin/* namespace, not even origin/master.  All
 fetching happens only into FETCH_HEAD.  This leads to confusion such as
 yours because origin/master and thus the upstream tracking displays will
 not know about the change.

I'll say. Now I'm really confused.

If what you say is true then what is updating origin/master? I've been
using git pull daily for over a year and origin/master is definitely
getting updated (at least according to gitk).

Mmm, just to make sure we are all talking about the same
origin/master: I mean my local reference to the SHA1 of the commit
that is master's HEAD on origin. After I have run git pull,  *my*
master and *my* origin/master point to the same commit. Or I'm
*really* confused. Or I've confused you by using incorrect
terminology. :-) Or by using the right terminology incorrectly. ;-)
--
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

Your branch and 'origin/master' have diverged

[Hilco Wijbenga]

Hi all,

A colleague of mine (after a relatively long absence) noticed the
following when running git status:

# On branch master
# Your branch and 'origin/master' have diverged,
# and have 250 and 19 different commit(s) each, respectively.
#
nothing to commit (working directory clean)

He asked me what to do and I told him to do what has always worked for
me in the past when something like this happened: gitk, reset master
branch to here (to a commit before the divergence and using --hard),
git pull origin master. Problem solved.

Well, not this one. This one is persistent. :-) I am at a loss what to
do. master and origin/master do *not* point at the same commit.
Even after the git reset --hard ... and git pull. Running my
silver bullet solution gets us in the same situation every time.

I checked his .git/config and it looks fine.

Any ideas? What information should I provide that might make it
possible for you to help me?

Cheers,
Hilco
--
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

On using receive.denyNonFastForwards and advice.pushNonFastForward

[Hilco Wijbenga]

Hi all,

I was wondering how hard it would be to make git push more adamant
about not pushing non-ff updates. So I wanted to see the effects of
receive.denyNonFastForwards and advice.pushNonFastForward. (By the
way, why is one plural and the other singular? That doesn't seem
consistent?)

HERE=$(pwd) 
git init --bare remote-repo 
cd remote-repo/ 
git config --add receive.denyNonFastForwards true 
cd .. 
git clone file://$HERE/remote-repo local-repo 
cd local-repo/ 
git config --add advice.pushNonFastForward true 
echo 1  one.txt 
git add -A .  git commit -m 1  git push origin master 
git checkout -b next 
echo a  two.txt 
git add -A .  git commit -m 2 
git checkout master 
echo 2  one.txt 
git add -A .  git commit -m 3  git push origin master 
git merge next 
git push

To my surprise there was neither warning nor error. Does this last
push really qualify as a FF update? Apparently, linear history and
FF-only updates are not the same thing?

Cheers,
Hilco
--
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