atom feed422 messages in org.kernel.vger.gitRe: What's cooking in git.git (topics)
FromSent OnAttachments
342 earlier messages
Johannes SchindelinJul 14, 2008 4:52 am 
Johannes SchindelinJul 14, 2008 4:57 am 
Johannes SchindelinJul 14, 2008 5:20 am 
Gerrit PapeJul 14, 2008 5:40 am 
Petr BaudisJul 14, 2008 5:43 am 
Johannes SchindelinJul 14, 2008 5:55 am 
Nicolas PitreJul 14, 2008 10:54 am 
Johannes SixtJul 14, 2008 11:54 am 
Junio C HamanoJul 14, 2008 12:00 pm 
Junio C HamanoJul 14, 2008 12:03 pm 
Junio C HamanoJul 14, 2008 12:16 pm 
Teemu LikonenJul 14, 2008 12:18 pm 
Johannes SixtJul 14, 2008 2:41 pm 
Johannes SixtJul 14, 2008 2:41 pm 
Johannes SixtJul 14, 2008 2:41 pm 
Johannes SixtJul 14, 2008 2:41 pm 
Johannes SixtJul 14, 2008 2:41 pm 
Johannes SixtJul 14, 2008 2:41 pm 
Lea WiemannJul 14, 2008 4:11 pm 
Lea WiemannJul 14, 2008 4:20 pm 
Junio C HamanoJul 14, 2008 5:02 pm 
Shawn O. PearceJul 14, 2008 7:51 pm 
Martin LanghoffJul 14, 2008 8:14 pm 
Nicolas PitreJul 14, 2008 8:30 pm 
Geoffrey IrvingJul 14, 2008 8:37 pm 
Johannes SixtJul 15, 2008 12:59 am 
Petr BaudisJul 15, 2008 2:08 am 
Petr BaudisJul 15, 2008 2:20 am 
Johannes SchindelinJul 15, 2008 2:21 am 
Dmitry PotapovJul 15, 2008 8:06 am 
Johannes SchindelinJul 15, 2008 8:26 am 
Avery PennarunJul 15, 2008 8:51 am 
Nicolas PitreJul 15, 2008 9:26 am 
Sverre RabbelierJul 15, 2008 9:46 am 
Geoffrey IrvingJul 15, 2008 9:48 am 
Dmitry PotapovJul 15, 2008 10:03 am 
Petr BaudisJul 15, 2008 10:27 am 
Junio C HamanoJul 15, 2008 11:51 am 
Johannes SchindelinJul 15, 2008 3:10 pm 
Junio C HamanoJul 15, 2008 3:32 pm 
Johannes SchindelinJul 15, 2008 3:45 pm 
Junio C HamanoJul 15, 2008 8:32 pm 
Junio C HamanoJul 17, 2008 1:08 am 
Stephan BeyerJul 17, 2008 6:08 am 
Nanako ShiraishiJul 18, 2008 1:50 am 
Junio C HamanoJul 18, 2008 2:07 am 
Nanako ShiraishiJul 18, 2008 2:19 am 
Junio C HamanoJul 18, 2008 2:42 am 
Petr BaudisJul 18, 2008 2:43 am 
Junio C HamanoJul 18, 2008 2:58 am 
Johannes SchindelinJul 18, 2008 4:55 am 
Johannes SchindelinJul 18, 2008 4:56 am 
Nanako ShiraishiJul 18, 2008 10:13 pm 
Junio C HamanoJul 18, 2008 10:31 pm 
Johannes SchindelinJul 19, 2008 4:19 am 
Junio C HamanoJul 19, 2008 9:54 am 
Johannes SchindelinJul 19, 2008 4:15 pm 
Junio C HamanoJul 19, 2008 6:58 pm 
Nick AndrewJul 19, 2008 7:23 pm 
Nanako ShiraishiJul 20, 2008 3:20 am 
Miklos VajnaJul 20, 2008 6:03 am 
Johannes SchindelinJul 20, 2008 6:16 am 
Junio C HamanoJul 20, 2008 11:27 am 
Johannes SchindelinJul 20, 2008 12:06 pm 
Junio C HamanoJul 20, 2008 12:58 pm 
Sverre RabbelierJul 20, 2008 1:03 pm 
Miklos VajnaJul 20, 2008 1:32 pm 
Junio C HamanoJul 20, 2008 1:33 pm 
Johannes SchindelinJul 20, 2008 3:23 pm 
Petr BaudisJul 20, 2008 3:40 pm 
Sverre RabbelierJul 20, 2008 3:57 pm 
Junio C HamanoJul 20, 2008 4:03 pm 
Jakub NarebskiJul 21, 2008 1:47 am 
Yaroslav HalchenkoDec 13, 2010 11:08 am 
Junio C HamanoDec 13, 2010 12:46 pm 
Yaroslav HalchenkoDec 13, 2010 1:46 pm 
Junio C HamanoDec 13, 2010 2:15 pm 
Yaroslav HalchenkoDec 13, 2010 2:35 pm 
Johannes SixtDec 13, 2010 11:22 pm 
Yaroslav HalchenkoDec 14, 2010 6:21 am 
Subject:Re: What's cooking in git.git (topics)
From:Junio C Hamano (gits@pobox.com)
Date:Jul 18, 2008 2:58:03 am
List:org.kernel.vger.git

Petr Baudis <pas@suse.cz> writes:

On Fri, Jul 18, 2008 at 06:20:10PM +0900, Nanako Shiraishi wrote:

I do not know if "I do not understand what they did well enough" is the only
reason people would want to use that feature. Isn't it better to let people
decide that for themselves?

It is dangerous to introduce new options just because we think someone, sometimes might find it useful, especially if they potentially encourage a bad workflow. Adding options and commands is expensive since it complicates the UI further, thus we should add further only when we have good reason for it.

That also was the reason I did not add any documentation to it.

I was actually looking for something like this based on some question on #git (about git pull -s theirs possibility), and did stumble upon these patches, but quickly gave up on them since it wasn't immediately clear for me from the patch description exactly how the workflow looks like (it doesn't really seem to work like the opposite of -s ours nor is it a separate strategy... huh) and the options were completely undocumented.

Heh, now you have some readings to do ;-)

I tried not to sound too negative when describing -Xours and -Xtheirs there, but actually I think "-s theirs" is even worse. It is how you would discard what you did (perhaps because the other side has much better solution than your hack), but that can be much more easily and cleanly done with:

$ git reset --hard origin

Some poeple might say "But with 'merge -s theirs', I can keep what I did, too". That reset is simply discarding what I did.

That logic also is flawed. You can instead:

$ git branch i-was-stupid $ git reset --hard origin

if you really want to keep record of your failure.

One big problem "-s theirs" has, compared to the above "reset to origin, discarding or setting aside the failed history" is that your 'master' history that your further development is based on will keep your failed crap in it forever if you did "-s theirs". Hopefully you will become a better programmer over time, and you may eventually have something worth sharing with the world near the tip of your master branch. When that happens, however, you _cannot_ offer your master branch to be pulled by the upstream, as the wider world will not be interested in your earlier mistakes at all.